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I . INTRODUCTION 



Timing in computer systems has been a critical issue 
throughout the evolution of computers. The most obvious areas 
where timing is of great concern are operating systems, 
distributed systems and real-time systems. In the most other 
areas, timing of a computer program is taken for granted 
since we assume a simple sequential execution of this 
program. But we have to realize that, when we consider the 
program and the machine on which it has to run as a whole, 
i.e. a computer system, we have to deal also with the 
internal timing of the hardware. Even though high level 
programming languages have provided us with the means to 
software from one system to another, we still find these 
programs may not work properly because of timing problems. 
These timing problems are normally caused by different 
implementations of computer resources. So It would be very 
helpful to have a way of comparing computer systems and 
predicting problems in timing when programs are transferred. 
It would even be much better to have specifications of 
computer systems that could be used to design transf errab 1 e 
programs in the first place. 

There is ongoing research at the Naval Postgraduate 
School on the formal specifications of computer systems that 
is mainly intended to overcome the increasing costs of 
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computer software resulting from problems with portability 
and reusability of programs. The first result of this 
research project has been the development of a formal 
specification methodology by Davis (1984). This methodology 
was successfully used to write a formal specification of an 
Abstract Processor by Yurchak (1984). ‘ This work was followed 
by several extensions of the Abstract Processor and related 
work by Hunter (1985) and Zang (1985). The research performed 
at the Naval Postgraduate School is part of a relatively new 
branch of computer science: the Science of Computing System 

Design which is concerned with a formal approach to the 
specification and description of computer systems. This 
thesis follows the direction of previous work done in this 
field. Its objective is to formally specify timing in 
computer systems. Even though there has been considerable 
interest in timing, our approach will emphasize two aspects 
of the problem: 

- We want to develop a formal way to specify timing to 
achieve the benefits of the rigorous foundation of a 
formal description. 

- We want to specify abstracted resources which include 
both hardware and software with a unified approach. 

Throughout this thesis the term ”computer resources” is 

used in a sense that combines all hardware and software 

building blocks of computer systems: memory, registers, data 

types, instructions, etc.. Also the special aspect we are 

‘An edited version of the specification of the Abstract 
Processor is included in Appendix A 
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concerned with is time as a computer resource. Computer 
resources can be either pure physical or they can be an 
abstract type. A memory cell belongs to the physical category 
while a specific data type belongs to the abstract category. 
The means to deal with these differences is abstraction. 
Specifying computer resources as abstractions in a 
mathematical way also allows us to compare different 
specifications and implementations. 

Within this work we will emphasize a practical viewpoint. 
Even though in applying pure mathematical concepts to 
computer systems we realize that computers are in no way 
ideal: as every piece of hardware is finite (especially the 
memory) and an event in the computer is never instantaneous 
but will take a certain amount of time. In this context, for 
example, the term **digital computer** is misleading since 
there are many undefined states between those defined **0** and 
"I". 

Therefore the goal of this thesis is to provide a 
methodology for the rigorous specification of timing: 

- to evaluate the time behavior of systems which leads to 
the exhibition of possible places in system where 
parallelism could be used, 

- to give a better understanding of the dynamic aspect 
of computer resources in time, and 

- to find time critical situations in a system. 
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I I . BACKGROUND 



A. FORMAL SPECIFICATION 

The idea of specifying a system formally is to deal with 
physical and abstract computer resources as abstractions to 
support our major concerns with portability and reusability. 
In this sense we deal with computer resources as abstractions 
which we want to describe such that the functions and the 
properties of a resource are stated in a mathematical way to 
support precision and provability. Studies in this direction 
have been conducted by many researchers (Goguen (1978), 
Guttag (1978), Bergstra (1983), and Davis (1984)). As a short 
introduction to this work we would like to present some key 
issues here as they were used in the first formal 
specification of the Abstract Processor. 

The formal specification of the Abstract Processor is 
based on the method of algebraic specification which consists 
of two parts: the interface specification and the constraints 
specification. The interface specification declares operands 
and the operators that can be applied to them, so information 
for syntactic constructions and type checking are provided. 
The constraints specification is a set of properties that 
define constraints on the operations. These properties are 
stated by equations that associate the same meaning to pairs 
of expressions of the specification. As an example the 
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specification of the computer resource **boolean** is shown in 
Fi gure 2.1. 



RBSOurcm boolean is 

Operands 

bool 

Opera tors 

not: bool -> bool; 
and: bool, bool --> bool; 
true: -> bool; 
false: -> bool; 

Properties 

not(true<)) = false(); 
not(not( x) ) = x; 
and(true( ) , x) = x; 
and ( fa 1 se ( ) , X } = false(); 

end boolean; 



Figure 2.1: Specification for Resource "boolean” 



Figure 2.1 illustrates the definition of one operand type 
(bool) and the operations (not, and, true, false) that are 
allowed with this operand. The operations are stated as 
functions with their input and output. Note here that the 
constants resembling "true" and "false" are obtained from the 
nullary operator functions with no input ("true()" and 
"falseO"). Up to this point only the interface part is 
considered. The meaning of the specification is indirectly 
in the form of equations that state that certain expressions 
must be treated identically to other expressions. The above 
equations use "x" as a free variable, i.e. "x" stands for any 
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expression that can represent an operand of type "bool". So 
far this computer resource "boolean” is an abstract data type 
in the traditional meaning. But computer resources also 
consists of physical resources which are very similar to 
abstract data types in their specification. Figure 2.2 
provides an example of specifying a physical computer 
resource to indicate the memory state of the Abstract 
Processor. For simplicity only the operands for 
initialization, fetching and storing are presented. The first 
interesting fact to note in this specification is that it 
states that the resource "amstate" is an extension of the 
previously defined specifications of the resources "boolean", 
"memaddress", and "regaddress" , i.e. all operands, operators, 
and properties defined in these specifications can be used to 
specify "amstate" without further explanations. The operand 
"state" has in this example four operators to initialize the 
processor, to fetch from memory and registers, and to store 
to memory and registers. The properties for these operations 
are shown by equations that indicate their relations among 
them. Note that this example uses the term "undefined" to 
indicate an error or don’t care condition (the attempt to 
fetch the contents of an register or memory address of a new 
initialized processor is illegal). 

The basic step in becoming familiar with formal 
specifications is to consider the well-known constructs of 
abstract data types: a class of objects together with a set 
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of operations that may be applied to these objects. This 
approach can also be applied to physical computer resources. 



Rmsource amstate is 



Extension of 
boolean, 
memaddress, 
regaddress. 



Operands 

state; 



Opera tors 

fetchm: 
fetchr : 
storem : 
storer : 
ini tarn: 



memaddr, state vai; 
regaddr , state -> val; 
va 1 , memaddr , state -> state; 
val , regaddr , state -> state; 
-> state; 



Properties 



fetchm(a, ini tam( ) ) is undefined; 
storem ( fetchmfa, q) , a, q) = q; 
i mpl i es ( eqmemaddr (al , a2) , 

fetchm(al , storem(v, a2, q) ) = v) 

= trueO ; 

imp! i es<not( eqmemaddr (al , a2) , 

fetchmCal , storem(v, a2, q) ) = fetchm(al,q)) 
= trueO; 



f etchr ( r , ini tarn () ) is undefined; 
storer ( fetchr < r , q) , r , q) = q; 
impi ies (eqregaddr <rl , r2) , 

f etchr ( r 1 , storer ( V , r2, q ) ) - v) 

- trueO; 

imp! i es (not (eqregaddr ( rl , r2) , 

fetchr (rl , storer (v, r2, q) ) * f etchr (rl , q) ) 

- true(); 



end amstate ; 

Figure 2.2: Specification of ’’amstate” 
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Then we have concrete algebras which describe an aggregate of 
operations and sets of values where the sets are the source 
for arguments and result types of each operation. This is a 
system in which there are sets and operations that are 
applied to elements of the sets such that the results of the 
operators stay in the system. When we construct a 
specification of such a system, we attempt to create a 
specification that serves as templates for the sets and 
operators in a concrete algebra and axioms which state 
provable equations about the values and operations. With such 
a specification we have something which describes the 
resource abstractly and precisely without restricting it to a 
specific concrete algebra, i.e. there can be many algebras 
that are implementations of a single specification. They are 
considered as the class of algebras uniquely associated to 
that specification. 

1 . Syntax versus Semantics 

We refer to the syntax of description as the "form” 
of the description and to semantics as the "meaning” of the 
description. 

The meaning is always determined by associating form 
to real objects. Basically the syntactic part describes legal 
expressions that can be formed with the operators in the 
specification. These expressions are called formal terms. The 
constraint part specifies that certain formal terms are to be 
considered equivalent. The meaning of specifications is 
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established by associating certain concrete algebras to the 
specification. There algebras represent the "real object". 
Operational expressions in the concrete algebras are called 
actual terms. Semantics are defined by a correspondence 
between properties of formal terras and actual terms. A real 
object is a realization of the abstract object defined by a 
specification under three conditions as they are stated in 
Davis and Yurchak (1984): 

- Condition 1: 

For each operand type of the specification there is a 
corresponding set of values in the real object and to 
each operator in the specification there is a 
corresponding operation in the real object that is 
defined on values that correspond to the operand types of 
the operator. 

- Condition 2: 

In the correspondence between formal terms and actual 
terms, two formal terms are provably equal if and only if 
their corresponding actual terms have the same value. 

- Condition 3: 

To every value of the real object there must correspond 
some formal term whose corresponding actual term has that 
value. 

These conditions provide us with a powerful insight: 
given a formal specification of some resources there can be 
different implementation in the real world (as they probably 
are on different machines), but as long as the 
implementations satisfy the above conditions they are 
equivalent. This is a very important property when the issue 
of portability is concerned. 

Still an formal specification despite its abstract 
view of resources has to deal with the real world: for 
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example there is nothing like true infinite memory so that a 
defined operator like ”nex tmemaddr ** (to obtain the memory 
address of the next instruction to be executed) will 
eventually exceed the physical implemented memory of a 
system. The "undefined" has been introduced in the formal 
specifications to act like a safeguard. It indicates that 
there is no interpretation in the realization for this term. 

B. PETRI NETS 

Petri Nets are tools for the study of systems through 
modeling. The Petri Net theory has been originally introduced 
by Carl Adam Petri in his doctoral dissertation (1962). 
Further studies of A. U. Hold and Jack B. Dennis helped to 
develop this theory. 

1 . Terminology of Petri Nets 

From Peterson (1981) a basic Petri Net is defined as 
a five-tuple M = (P,T,I,0,m) which is composed out of the 
following parts: 

- a set of places P 

- a set of transitions T 

- an input function 1 

- an output function 0 

- a marking vector m 

The function 1 is a mapping from a transition tj to a 
collection of input places 0(tj) and the function 0 is a 
mapping of a transition tj to a collection of output places 
I(tj), the marking vector m indicates the number of tokens 
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preset in each place. In this general form, developed by C.A. 
Petri, a place can hold more than one token at a time. 2 

As an example, the following net structure is 
presented here and Figure 2.3 shows its corresponding graph 
in the common symbology of Petri Net graphs where circles 
indicate places, bars indicate transitions, and arrows show 



the connections between places and transitions: 



M = (P,T, l,0,m) 

P “ ipl # P2 > p3 t p4 f pS f pA f p7 

T — iti , ta f ta , t4 f tg } 
m = ( 1 , 0, 0, 0, 0, 0, 0, 0) 



I ( ti ) = {pi } 0( ti ) 

I ( t2 ) = {pi } 0(t2 ) 

I ( t3 ) = { P 2 » P3 } 0 ( t3 ) 

I ( t4 ) = { P4 , Ps } 0 ( t4 ) 

I ( tg ) = {p^ , P7 > 0( tg ) 



p. 


} 




II 


< P2 


► P4 } 


II 


fPs 


} 


11 


tPs 


. P. > 


II 


<P7 


} 


II 


( Pa 


} 




Figure 2.3: Graph of Petri Net 



The following Petri Net terminology is used in this thesis: 

- place = a construct for modeling conditions of the system 

- event = actions that take place in the system 

- token = a construct used to indicate that a condition 
holds (a true condition) 



^ The reader is referred here to the BAG theory 
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- transition = the process of recognizing true 
preconditions, the occurrence of an event, and making the 
postconditions hold 

- concurrency » two or more events depending on different 
preconditions can occur in any order 

- conflict = only one of two or more events depending on at 
least one common precondition can occur 

To give a simple description of Petri Nets we can say the 
following: An event occurs (a transition is initiated or 
enabled) when all of its preconditions hold. The effect of 
the occurrence is that the tokens of the preconditions are 
"used" for the event and then distributed to the 
postconditions. 

The following constructors can be recognized in Petri Nets: 

- simple transitions •> - there is one precondition and 
whenever this condition holds the event occurs so that 
the token from the precondition is removed and after the 



occurrence of 


the event 


the token 


1 s 


moved 


to the 


postcondi tion 
2.4). 


so that this 


condition 


now 


holds 


( Fi gure 


conjunctive 


transitions 


= there 


are 


two 


or more 


precond i t i ons 


that a 1 I have 


to hold 


in 


order 


for the 



event to occur. All tokens of the preconditions are used 
and after the occurrence of the event only one token is 
moved to the postcondition to indicate that it now holds 
(Fi gure 2.5). 

- disjunctive transitions = one precondition is connected 
to two or more events and when this precondition holds 
one of the events will occur and will move the token from 
the precondition to the postcondition of that event that 
occurred. The selection of the event to occur is 
non=deterministic (Figure 2.6). 

- distributive transitions = there is one precondition and 
when this holds the connected event will occur. It will 
remove the token from the precondition and it to all 
postconditions so that every postcondition of this event 
will have a token (Figure 2.7). 

- complex transitions > combinations of the above simple 
constructs of Petri Nets. 
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Figure 2*4: Simple Transition 
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Figure 2.5: Conjunctive Transition 
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before euent after euent 





Figure 2.6: Disjunctive Transition 
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Figure 2.7: Distributive Transition 



2. Properties of Petri Nets 

Petri Nets by their nature are well suited to model 
asynchr onuous processes, i.e. where the progress of a process 
is controlled by conditions and events and not by some kind 
of fixed clock. This means that in some part of the net there 
can be waiting for a condition to start an event, even the 
case that a process cannot continue because of a missing 
condition. Suppose an event is modeled as a conjunctive 
transition as indicated in Figure 2.5. If the precondition 
Cp r • t is never true the process will stop at this point. The 
"flow" of the progress can always be observed by the state of 
the condition places in the system. The occurrence of events 
is recognizable by the changing of the preconditions and 
postconditions. 
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The discussion of disjunctive events has shown an 
important property of Petri Nets: their non-deterministic 
nature, i.e. we have under normal circumstances to force a 
distributive construct in one or the other direction. This is 
a major obstacle when we have to model some kind of decision 
making in a Petri Net. One way to get around this problem is 
the construct (introduced by Peterson (1981)) of an "external 
agent" which provides appropriate TRUE or FALSE places at 
decision points in the net. Here by the intervention of the 
"external agent" the process proceeds in the direction of the 
TRUE or FALSE place. In general, one can think of "external 
agents" as CASE-cons tructs in high-level programming 
languages such that, dependent on the value of an argument, 
one and only one action is taken by setting the according 
place in the net. We will discuss this topic further in 
Chapter IV. 

When we look at the conjunctive and distributive 
constructs we observe that by combining them we can build a 
distributive construct which "fans" out into several holding 
places and then combines again with a conjunctive construct. 
In this way, we have able to introduce parallelism into Petri 
Nets. Figure 2.8 shows the graph of a process that fans out 
into five processes which then merge again into one process. 
This capability of Petri Nets is very powerful and convenient 
in specifying computer resources. 



22 




Figure 2*8: Parallelism with Petri Nets 



3, Modeling with Petri Nets 

Modeling with Petri Nets has been widely used in very 
different areas: computer software, computer hardware, 
chemical reactions, queuing theory, political systems, etc.. 
Two examples as they are presented by Peterson (1981) are 
given to illustrate this modeling work: a portion of a Petri 
Net showing a control unit of a computer with multiple 
registers and functional units as an example for modeling 
computer hardware (Figure 2.9) and a Petri Net dealing with 
the mutual exclusion problem as example for modeling computer 
software (Figure 2.10). 

In our approach we want to exploit the ease and the 
properties of Petri Nets for modeling the combination of 
computer hardware and software as they operate in time. 
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Figure 2*9: Computer Control Unit 




Figure 2.10: Mutual Exclusion 
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in. THE PROBLEM OF TIMING SPECIFICATION 



A. GENERAL PROBLEMS 

Why are we so concerned about the timing of a system? 
Time is an important resource in computer systems that must 
be managed carefully. There is almost always the possibility 
that if we invest more of other resources we are able to 
reduce the amount of time a piece of work will need. 
Everybody remembers a mathematical problem like this: if it 

takes one unit to accomplish a task in x hours how many hours 
will it take y units to do the same task? In this very simple 
problem the increase of other resources (e.g. units) will 
reduce the needed time for the task linearly. In computer 
systems we could save time by implementing more CPUs, disk 
drives, arithmetic units, etc.. But since more hardware costs 
more money and the control of additional resources uses time 
by itself we have to be very careful in determining the 
resources we need and how we use them. The following example 
shows the danger of mismanaging computer resources: a 

computer task that requires some resources (e.g. disks) would 
waste them if it holds more than it needed at times when it 
actually does not need them and so prohibits other tasks from 
using them. 

The formal specification as described in the 
specification of the Abstract Processor is only concerned 
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with static computer resources, i.e the timing properties are 
implied by the functional relations between components of the 
system. The static specification is purely functional. For 
example, operands must be evaluated before a function is 
applied but there is no way of indicating the order of 
evaluation. The dynamic computer resources are those that 
express an ordering of resources in time, mutual exclusion 
and concurrency. Instead of assuming some ordering in the use 
of computer resources we want to be able to explicitly state 
and define the timing of a system. 

The goal is to specify the required timing properties 
precisely to a desired degree which for example is sufficient 
to evaluate the system for time and cost efficiency. The 
relation between time and cost depends on the nature of the 
system: there is much more emphasis on time in system that 
are very time critical (e.g. real-time systems) and not so 
much on systems that are purely problem solvers. 

The basis of this work is to show whether such a 
methodology for specifying timing properties can be based on 
the theory of Petri Nets and how well the special cases of 
timing in computer system resources can be expressed in terms 
of Petri Nets. 
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B. SPECIFIC PROBLEMS OF INTEREST 

1 . Order of Evaluations of Functions 

Given a function f ( xi , X 2 , . . . , x„ ) we only require that 
Xt to Xn are evaluated before f can be applied.^ There is no 
statement that the evaluation of Xt has to be started first 
or what evaluation has to be completed first. 

2. Parallel Processing of Parts of Functions 

Considering again our function f ( Xi , Xs , . . . , x„ ) we 

want to state explicitly which evaluations have to performed 
in parallel and which in sequence. Why do we want to do so? 
Following our purpose, in the specification we want to 
describe timing in a way which is as exact and detailed as a 
timing diagram used to construct hardware. 

3. Mutual Exclusion 

A major problem that arises with parallelism is 
mutual exclusion, i.e. a computer resource can only be used 
by one process at a time and the use of the resource has to 
have a certain entry and exit point to preserve the integrity 
of the resource. 

Consider a simple computer with a memory unit which 
retrieves and stores data on request via a specified 
interface (Memory Buffer Register and Memory Address 
Register). This is parallelism even in simple computers since 
the memory is independent from the CPU. So we have to make 



’Even if X is a constant it has still to be evaluated, 
i.e. its value has to be retrieved 
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sure that only one request is handled by the memory unit at a 
time and that the next one is handled when the first one. is 
finished. We want to be able to explicitly state those 
properties in the specification of timing systems. 

4. Data Flow 

During the course of a process in time certain data 
has to be available in order for the process to proceed. Some 
data is changed, other data is not needed anymore. Here we 
have the problem of how to model data flow by means of Petri 
Nets. 

To make this point more clear let us consider the 
execution of following instruction: SUB R1,R2 (subtract the 
contents of register 1 from the contents of register 2 and 
store the result in register 2). During the execution we have 
to retrieve the identities of the registers from the 
instruction (i.e. the instruction has to be decoded) then 
their contents both have to be available before we can 
perform the subtraction. At this point of the execution we do 
not need the identity of the first register anymore, but the 
one for the second since it is not only a source for the 
operation but also the destination. Thus, we have to have 
some mechanism in our methodology to state data which is 
available during the course of the execution. 
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IV. APPLICATIONS OF PETRI NETS TO THE TIMING IN FORMAL 



SPECIFICATIONS 



In previous work computer resources have been formally 
specified using basically the algebraic specification 
approach. In essence, this is a type of functional 
specification. The question we address here is can functional 
specification be extended, using Petri Net theory, to provide 
for the specification of timing properties. 

A. GENERAL APPROACH 

Given a general function f ( x , , Xz , . . . , x„ ) what are the 
stages of evaluation for this function? 

- the evaluation of f < x, , Xj , . . . , x„ ) must have been 
requested from somewhere and by this the evaluation gets 
into a requested stage 

- for sll Xj^ j evaluation is requested 

which starts for all x, a new process with the same 
stages as described here 

- once all x, are evaluated and their results are available 
to our function f it can be evaluated in a processing 
stage 

- when the evaluation is completed and the result is 
available the process is completed 

Note the similarity to the "natural" way a human being 
would calculate this function: if we were to calculate 

sum(sin(x* ) , sqrt(y) } we had to calculate the square root of y 
and we had to square x and take the sine of it and then we 
would apply the sum-function to the intermediate results. 
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However, this example exhibits a problem for our very general 
approach: how do we know what the values of x and y are and 
how do we know that e.g. "sqrt" means "take the square root". 
Therefore there must be some decoding and retrieval steps in 
between which determine what the parts of the function 
expression mean. This is exactly the case when we consider 
computer instructions: e.g. given an instruction like "ADD R1 
M2 R3" which means "add the contents of register 1 to the 
contents of memory address 2 and store the result in 
register 3". Here the following steps have to be performed: 

- The instruction has to be decoded (we assume that at this 

stage the instruction is already retrieved): i.e. the 

components of the instruction (operator and operands) 
must be made available to the further evaluation. 

- Up to this stage only the names (i.e. the symbolic 
addresses) of the operands are available and so the next 
step is to retrieve the values of the operands. 

- Now that the operator and the values of the operands are 
available the operation designated by the operator can be 
performed. 

- When the result is available it can be stored into the 
location which expressed by the third operand. 

Figure 4.1 shows the corresponding graph of a Petri Net 

describing the above steps. In this example we see an 

approach to describe the execution of an instruction in a 

sequential manner. Suppose we had a machine that could 

perform retrieval of values and operation in parallels, how 

could we describe that certain steps could be performed in 

parallel and how could we mark points in time where the 

process can only proceed if some results are available? 
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Figure 4.1: Simple Instruction Execution Net 



This is the point where we can use the properties of 
Petri Nets: if we model requests and availabilities as places 
of Petri Nets and the actions on requests and availabilities 
as transitions and connect them accordingly we are in a 
position to model the evaluation of a function or the 
execution of an instruction. 

Up to this point there is nothing new in our methodology 
since modeling with Petri Nets is common practice and has 
been done for a long time. The question to be ask now is does 
a methodology based on Petri Nets provide the means to 
specify the specific problems of computer systems and their 
components in a way that is consistent with the formal 
specification of the static properties we have seen in the 
specification of the Abstract Processor. 

In addition we not only want to look at the timing of 
systems in an isolated fashion, but also we want to combine 
the specification of static properties, as introduced in the 



31 



with 



the 



specification of the Abstract Processor, 

specification of dynamic. properties of such a system. With 
this combination we can specify systems completely. 

B, NOTION OF SUBNETS 

Now that we have Petri Nets as a tool we can model simple 
timing systems using our methodology. However, we would like 
to simplify and eliminate redundancy: if we use the same 

structure in a net several times, it would be better to have 

this structure defined once and reference this definition 
wherever we need it in our system (Figure 4.2). As an 
example, suppose we realize that a structure to make the 
contents of a certain memory address available to the process 
appears several times in our system. By defining this 

retrieval -function as a subnet we are in a position to use it 
everywhere in the system simply by setting its ENTRY-pIace 

(in our example with a request for value of a specified 
register) and we obtain the result (the value of the 

specified register) at its EXIT-place. This works even for 
the case that the subnet specifies a computer resource that 
has to be accessed observing mutual exclusion. 

The major question that has to be asked here is how can 
we model such a subnet that has the ability to "sense” where 
it has been invoked and so can return its results to that 
location in the system. Computer language constructs like 
procedures or functions use a return address which is saved 
with the call of the procedure/function to determine the 
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location in the program which has to be executed after the 
pr ocedur e/ f unct i on is finished. Our model of using Petri Nets 
is different in this aspect: despite the fact that it shows 
the dynamic behavior of a system, its structure is static and 
does not change in time and so all connections between nets 
and subnets are established. Since we have to know all these 




Figure 4.2: Symbology of Subnets 



connections we are able to provide for each connection an 
entry-place which is connected to the net internally by 
disjunctive events such that only one can be "fired’" at a 
time. The "firing" of those events lets a path-place hold 
that indicates the entry-place which triggered the event. 
This path-place decides what exit-place is set when the 
internal net provides the result. 

This definition of a subnet is a very powerful shortcut 
for keeping descriptions of systems limited. It resembles a 
function construct in a high-level programming language: it 
is been "called" by setting its request-place, does its 
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supposed work and "returns*^ the result as the available- 
p lace • 




Figure 4.3: Generalized Subnet without Mutual Exclusion 




Figure 4.4: Generalized Subnet with Mutual Exclusion 
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We have to show that our methodology is capable of 
defining subnets and introducing them into other nets. 



C. COMBINING NETS 

With the introduction of subnets we are in need of rules 
and guidelines on how we can combine a collection of small 
nets and subnets into a timing system. 

1 . Coupling of Nets 

In the preceding paragraph we have assumed that nets 
are connected by entry and exit places, but generally, we 
have two possibilities to connect nets: 

- Coupling by places: to connect two nets the first net 

outputs to a EXlT-place that is read by the second net as 
an ENTRY-place. In the special case that we use subnets 
in our specification we request the subnet by place (the 
ENTRY-place of the subnet) and obtain the result by a 
place (the EXIT-place of the subnet). 

- Coupling by events: events are shared between nets and 
when the ENTRY-event "fires" the requested net is invoked 
and signals the availability of the result by "firing" 
its EXIT-event. 

We have chosen the coupling of nets by places because 
of the following reasons: 

- The request for a subnet submitted by a place allows the 
requested subnet more "liberty" to react on the request 
only when it is ready to do so since the pending request 
as a "loaded" place remains until it is used by the net, 
where as in event-coupling the saving requests had to be 
done in a more complicated way. 

- The coupling of nets by places resembles the way events 
like interrupts are processed in real machines, here the 
interrupt does not interrupt the execution of 
instructions at any time, but a status "interrupt" is set 
and this status is checked between the execution of 
instructions and acted upon. 
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2 . 



Extensions of Nets 



To make our methodology consistent we need to state 
what other nets we are going to use in this net. There is a 
close similarity to INCLUDE, USE or WITH constructs of high- 
level programming languages or the EXTEND construct of the 
formal specification. In the specification of timing the 
mentioning of a net to be the extension of another means that 
the parent net is going to use the extended net as a subnet 
in the specification. 

3. Net Selection 

Due to the non-deterministic nature of Petri Nets we 
do not have a traditional net construct which can make 
decisions on truth or falseness and directs the path in the 
net accordingly. A proposed solution for this problem by 
Peterson (1981) is to use "external agents" as they were 
presented in Chapter 2. This construct is able to examine a 
status or data on a given condition and make the decision 
whether the condition is fulfilled. With the outcome of the 
decision a path to a place representing true or the place 
representing false is set. By extending this idea we able to 
think of "external agents" as a CASE-s tatement where one and 
only way through the net is chosen according to a condition 
(see Figure 4.5). 

D. TYPING OF NET ELEMENTS 

In the traditional Petri Net theory we have tokens to 
indicate the flow through the net and to mark holding places. 
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So the "firing" of an event consists in collecting a token 
from each of the connected input places, performing the 
designated action and distributing a token to each connected 
output place. This is not enough when we want to describe the 
flow of data in time. Also we want to be able to state 
specifically what kinds of data, what types of data are being 
requested, available or transferred at a certain point in the 
timing of a system. 




Figure 4.5: Net Selection by "external agents 



How can we show the presence of data in our methodology? 
On first sight we have two possibilities: either we introduce 
a typed place or a typed token. Both of these constructs 
could indicate the presence of certain data. So we to examine 
both methods under the consideration which of them suits our 
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goal better to develop a practical and understandable 
methodo 1 ogy . 

1 . Typed Places 

When we introduce a concept of typed places we still 
have the original meaning of the tokens to indicate the 
holding of a place. The presence of data of a certain type 
must be accomplished by means that have to obey the type of 
the place. The events still react on the presence of tokens 
in the places. 

2. Typed Tokens 

This alternative considers a token as a construct 
that carries an actual piece of data according to the type of 
the token. We can imagine tokens as a message residing in the 
places. The events now can be modeled by picking up a message 
from each connected input placed, performing their designated 
actions, and distributing a message to every connected output 
p 1 ace . 

So now we can look at places in a net as constructs 
that can receive token-messages from events, keep them and 
send them to events. The actions performed by events consist 
of picking up message- tokens from places, changing and 
creating message- tokens and sending them to places. 

3. Typed Tokens in Typed Places 

Both concepts above exhibit some disadvantages: 

- Pure place typing needs some external mechanism to 

establish the presence of data. 
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- Pure token typing allows a message- token to be sent to 
every place in the net since there no protection from 
receiving message- tokens of the wrong type. 

This leads to the idea of combining both typing 
schemes. With this concept we restrict places in the net to 
accept only tokens of a certain type and the tokens are 
actually typed messages. One small problem does arise heres 
what if we want in some situations the token to have its 
original meaning only to indicate its presence without any 
data? This reminds of a message without contents. As a 
solution we introduce following typing convention: 

- A place declared to be of a certain type or collection of 
types can only accommodate tokens that are messages of 
this type or collection of types. 

- A place declared to be of no type can only accommodate 
tokens which are ’’empty” messages. 

- An event will collect typed token-messages from the 
connected typed input-places, perform its designated 
action and output typed token-messages to the connected 
typed output-places. 

With this typing scheme we are now in a situation to 
specify data flow in time by means of typed tokens and 
places. Although we have based our work on Petri Nets we see 
that our concept has become more general and now reminds of a 
general message passing system. 



E. SYNTAX 

Since our approach includes the existing specification 
methodology of the static computer resources, we have to 
carefully develop a new syntax which expresses both the 
static and dynamic properties of the systems to be specified. 
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The following syntax has been introduced with the 
specification of the Abstract Processor by Davis and Yurchak 
(1985) : 



Resource <name> is 
Operand Types 

<operand types> 

Operators 

<operators> 

Properties 

<properties> 

The following requirements have to be fulfilled by the 
syntax we want to develop: 

- It has to have the ability to express both the static and 
dynamic properties of system properties where the static 
part should be left in the form as introduced by Davis 
and Yurchak (1984). 

- The form of the syntax should be as simple and easy to 
understand as possible. 

- The chosen names of the constructs cf the syntax should 
be self-explanatory and suggest the intended meaning to 
the user. 

- It has to provide a precise and unambiguous way to 
specify the system. 

Another point to consider is that we want to follow 
certain accepted design principles, especially that of 
Information Hiding as it is done e. g. in the ADA package 
ccnstruct where there is a Package Interface (to provide the 
user of the package with all the infcrmation necessary tc use 
the package and nothing else) and a Package Bcdy (the 
implementation of the package). 

Before we finalize the syntax for the dynamic 

specification of a system we need to say something about how 
the dynamic properties of static objects are described in 
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terras of places and transitions. Places reflect the 
conditions on the execution of the static functions, whereas 
transitions are used to describe changes in these conditions 
during the execution of the static functions. Some of these 
places and transitions are generic, i.e. they apply to any 
function. For example, a function is always requested by a 
place and becomes activated by an aoti vate-trans i t ion. This 
does not prevent us from defining additional places and 
transitions when they are needed for a specification. We are 
going to use an uniform notation to indicate the connection 
between the statement of the dynamic properties and the 
static properties. Given an operator storem : val, memaddr, 
state -> state we will use internal places names that are 
preceded by storem_ (e.g. s torem_act i vated ) and transition 
names that are followed by _storea (e.g. acti vate_storem) . We 
also reserve standard notations for entry and exit places of 
subnets: entry places are always preceded by roq_ (e.g. 

req_storem for "request a store in memory") and exit places 
are always preceded by avail__ (e.g. avail_storem for "result 
of store in memory is available). We reverse the order of 
attaching the name of the function because we want to 
emphasize that a subnet represents a transition that is 
specified in detail. 

1 . P 1 aces 

There are three types of places we want to 
distinguish in our syntax: 
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- internal placesi which names and definitions are only 
known and accessible within the net they are defined in; 
the purpose is to build the internal structure of the net 

- entry places, which names and definition are also known 
and accessible to those nets which are declared to be 
extensions of this net; they provide an interface to 
invoke this net 

- exit places, which names and definitions are known and 
accessible to those nets which are declared to be 
extensions of this net; they provide an interface to 
obtain the results from the invocation of this net 

We have chosen the following syntax to describe 
places in our specification: 

place_name<net labe 1 > CMessage_typs]. 

A place_name is the distinct name of a place in the described 
net. In the case that a place is either an entry or exit 
place the rule applies that their names are known to those 
nets which are declared to be extensions of this net. If a 
net has multiple entry or exit places the parameter netlabel 
can be attached in parentheses to describe this fact where 
netlabel indicates a location in the system. As we have said 
a place is able to accommodate a certain kind of message so 
the type of the message the place can hold in brackets is 
part of the place description. The following description of 
places are legal (compare with the static specification for 
"fetchr" and "storem" in Chapter II): 

- storem_activatedCval .memaddr. state] I a place of the name 
”storem_act i vated” which can hold messages that consist 
of data of type val, memaddr and state 

- f etchr_avai 1 C 1 ; a place of the " f etchm_avai 1 " which can 
only hold empty messages 
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- req_pushstk(net label ) Cval . stkaddr. state] ; places of the 
name **req_pushs tk" which are distinguished by the 
parameter "netlabel”, all of them able to hold messages 
which contain data of types val, stkaddr and state. 

2. Transitions 



Our methodology defines transitions as the process of 
collecting a message from each connected input place and 
sending messages to every connected output place. So we want 
to state what kind of messages are received and transmitted. 
The following syntax is used to describe transitions: 
transi tion_name: input_messages -> output_jDes sages. 

The transition name is a distinct name for the transition in 



the net and is not known outside the net. Input and output 
messages are of the above form where multiple messages are 
separated by commas. The following examples are legal 
description of transitions: 

- perf orB_8toreB: Cval .memaddr. state) -> [state] ; 

the transition of the name "per f orm_storem** takes a 
message which contains data of type val, memaddr and 
state as input and outputs a message containing data of 
type state 

- f inish^f etchr : Cval]tC] -> Cval],C]; 

the transition of the name "f ini sh_f e tchr " takes two 
messages as input where one consists of data of type val 
and the other is an empty message and outputs again two 
messages of same type 

Note that the description of transitions only 
declares them in terms of their capabilities to accept and to 



transmit certain kinds of messages 
internal action of the transition, 
present the transitions as building 
of a mapping function which is 



and does not show any 
The reason for this is to 
blocks of the net in form 
general enough to provide 
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information about its interface and nothing more. The 
internal actions are described as the properties of the net. 
This does not necessarily means that a transition is 
instantaneous, rather the complexity of the internal actions 
determine the duration of the transition. But every complex 
transition can be modeled as a net with entry and exit places 
such that the internal transitions become instantaneous. 

3. Properties 

Now that we have described the building blocks of a 
net we need to connect them in order to describe the intended 
timing of a system. The following form is chosen for the 
syntax of the properties of the net: 
t rans i t i on_name ( p I ace_names t message_data ) »> 

pIace_jnaaesCm«ssage_datal ; This form shows how places and 
transitions are connected and how the transfer of message 
elements occurs between them. Here are some examples of legal 
property descriptions: 

- perform_fetohm<fetohn_aotivat*dCa.q]> ■> 

f etcha_jcompletedC v] ) the transition "perf orm_f etchm” 

occurs when there is a message in the place 

"f etchm_acti vated” . The message is taken from the place 
in such a way that all message elements (memaddr m and 
state q> are available to the transition. Then the action 
of getting the memory contents is performed and the 
resulting value v is transmitted as a message to the 
place ”f etchm_corap 1 eted" 

- perf orm_storor <storer_activatodt V. r . q] ) «> 

8torer_completedCql I ; the transition "perf orm_storer" 

occurs when there is a message in the place 

"storer_act i vated" in such a way that the message is 
taken from the place in such a way that its message 
elements (value v, regaddr r and state q) are available 
to the transition. The action of storing the value v in 
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regi ster r is performed and the new state qi is 
transmitted as a message to the place "storer_comp I eted” 

Functionally, the internal actions performed by 

transitions follow the rules stated as static properties for 
the functions involved. 

4. Initial ization 

In some kinds of nets we have an internal circuit of 

places in order to act as a synchronization mechanism (as 

illustrated in Figure 4.4 to provide mutual exclusion). They 

have to be initiated somehow i.e. a message has to be placed 

in at least one of these places since they are not provided 

with messages from outside the net. We going to describe this 

initialization by using the symbol ”=>** used to indicate the 

placement of a message into a place. The following is an 

example of an initialization: 

>> f etchni_avai 1 ( ] ; the place "f etchm_avai 1 ” is loaded 
with an empty message 

The initialization of a place is a one-time action at 
the beginning of system start and provides the necessary 
conditions to get a process going. It can be viewed as 
establishing the initial state of a computer system when it 
is turned on. 
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V. THE ABSTRACT PROCESSOR TIMING SPECIFICATION 



In this chapter we want to present some examples on how 
specific problems of timing in computer system can be modeled 
using the methodology in a top-down fashion. The examples 
resemble a variety of computer system timing problems to test 
the use of Petri Nets in specifying the timing properties. In 
Appendix B a complete specification of the static and dynamic 
properties of a reduced Abstract Processor is presented. We 
have chosen to use the Abstract Processor as the object to be 
specified in timing considerations because of the following 
reasons : 

- to emphasis this work as the logical step following the 
work of specifying static properties of systems, 

- by specifying a non-existent, abstracted processor we 

intentionally leave the issue of the actual 

implementation untouched since we stated that by whatever 
means the specification is implemented the processor will 
have the specified properties, 

- to emphasize our intention of specifying what the user of 

a processor wants to achieve and not how it is 

implemented as compared to a traditional processor design 
approach that is dominated by engineering and 

implementation issues. 

Also we want to show how well our methodology can deal 
with the special aspects of timing in computer systems. The 
special aspects we are concerned with are mutual exclusion, 
interrupt processing and concurrency. Despite the fact that 
the Abstract Processor is in its static part specified as a 
simple single processor during this work we have realized 
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that even there, a lot of potential concurrency can be 
detected . 

Whenever we refer to actual implementation we do this 
with the intention to give one example of how the 
specification could be realized. Once again we emphasize that 
the methodology stated in this work is only concerned with 
what is available in a system and not with the how it is 
implemented. We want to remind the reader that the 
methodology developed here is intended to be general. That 
is, it can be equally applied to the specification of 
computer resources that may be implemented in hardware, 
software or firmware. With this in mind we have look at the 
timing specification not as a blueprint by which a system can 
be build directly but rather as formally stated requirements 
a system has to fullfil no matter what approach is chosen for 
the implementation . 

A. ATOMIC NETS 

One feature of the methodology is it forces the specifier 
to focus on the essential nature of the system components. 
When we consider these essential components as actions in a 
system that are not further divisible we can speak of atomic 
actions which we want to specify as atomic nets in our 
methodology. Such nets will use no other net in their 
specification and so can be considered as building blocks of 
a system. In general they represent the elementary actions in 
a system. The Abstract Processor consists of several such 
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elementary actions and to illustrate this idea, we will show 
how the actions of store operations and fetch operations can 
be described with atomic nets. 

B. MODELING OF MEMORY AND REGISTER ACCESS TIMING 

The first question we have to ask when we want to specify 
the access of memory or registers is what kind of information 
do we have to have available to perform an access and what 
information we obtain after the access has been made. In 
order to perform an access the address of the memory cell or 
register has to be available. Depending whether a store or a 
fetch has to be performed, we either have to provide a value 
for this process or we obtain a value from the process. Also, 
to indicate the current contents of the register or memory 
cell we have to indicate the process for accessing the state 
of the processor. In case of a store access we obtain a new 
state as the result of the process since the change of a 
memory cell or register also changes the state. 

At this stage we have established the components of any 
process dealing with the access of memory or registers. Ue 
anticipate that accesses to memory and registers will be made 
from various places in the system, so we provide a netlabel 
for every entry and exit place. In terms of our specification 
methodology can now define the entry and exit places of the 
subnet : 

- the fetching of the contents of a memory cell is 
requested by providing message which consists of the 
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memory address and the state to the following entry 
place : req_fetchn( net label ) Caeaaddr. state] } 

- We obtain as a result a corresponding message containing 

the value from the exit place: 

avai l_f etchffl(net labe 1 ) [val ] ; 

- similarly we state the entry and exit places for fetching 
the contents of a register: 

req^fetchr (net label ) C regaddr. state] ; as the entry place 
and avai l__fetchr (net label > C val ] ; as the exit place 

*■ the storing of a value into a memory cell is requested by 
providing a message which consists of the value to be 
stored, the memory address and the state to the following 
entry place: req_storem(netlabel ) C val .menaddr. state ] ; 

- We receive as a result a corresponding new state from the 
exit place: avai l__storem(net label ) Cstate] ; 

- similarly we define the entry and exit places for storing 
values into registers; 

req_storer (netlabel ) (val . regaddr. state] ; as the entry 
place and avai l^storer (netlabel ) (state] ; as the exit 
place. 

To show the versatility of the proposed methodology we 
will specify memory and register access differently: we are 
going to specify memory access in a way that allows only one 
access to one memory cell at a time (an implementation for 
this method might be a single memory unit allowing only one 
access at a time). On the other hand we might want to able to 
access registers in parallel. These requirements determine 
the internal structure of resulting specification. 

Considering the above requirements on how we have to 
specify the system we realize that we have to construct the 
specification to deal with memory accesses and accesses to 
each register separately. 
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As the next step we are going to specify the memory 
accesses. Since we know from our requirements that only one 
access at a time is allowed to the memory we have to provide 
a mutual exclusion mechanism in our specification that makes 
sure that the memory is not accessed by more than one request 
at a time. 

From Figure 5.1 we see that from any system location 
indicated by a netlabel a message in an entry place to 
request a memory access can only trigger a transition to 
activate the process when the process is available. Since 
there is only one empty message to indicate the availability 
of the net only one request can be honored at a time. The 
availability is restored when the access is completed. Also 
we see that the internal places "processed_f or " serve as 
traffic signs to direct the results to the appropriate exit 
places. Drawing the picture of the net can be helpful to the 
process of specifying net just as flow charts can be helpful 
in programming tasks, but our intention is primarily to state 
a formal specification. The following is the dynamic part of 
the memory access specification expressed in precise syntax: 
entry places 

req_f etchmCnet label ) imemaddr. state] ; 
req_s torem(net labe 1 ) i va 1 . memaddr . state ] ; 

exit places 

avail _f etchm (net 1 abe 1 ) C va 1 ] j 
avai 1 _s torem ( ne 1 1 abe 1 ) C state ] ; 

internal places 

access_avai 1 C 1 ; 
f e tchra_f or (netlabel )C3; 
fetchm_activated [memaddr. state] ; 
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f e tchm_comp 1 e ted [ va 1 ] ; 

storera_f or (netlabel)C]; 

storem_act i vatedt va 1 . memaddr . state ] ; 

storem_compl etedC state] ; 

initial state 

= > access_avai 1 [ ] ; 

transitions 

act_fetchm: [memaddr. state] ,[ ] -> [memaddr . state ],[] ; 

per f orm_f etchm : [memaddr . state ] -> [val]; 

f ini sh_f etchm : [val],[] -> [val],[]; 
act_storem: [ va 1 . memaddr . state ],( ] -> 

[val .memaddr. state], [ ] ; 

per f orm_storem : [val . memaddr . state] -> [state]; 

f i ni sh_s torem : [state], [] -> [state], []; 

properties 

act_f etchm(req_fetchm( 1 1 ) [m. q] , access_avai 1 [ ] ) => 
f etchm_for ( 1 1 ) [ ] , f etchm_activated[m. q] ; 
per for ra_f etchm ( f etchra_activated[ra. q] ) => 
f etchm_compl eted[ v] ; 

f inish_f etchm(fetch_compl eted[ v] , f etchm_f or ( 1 1 ) [ ] ) => 
avai l_f etchm ( 1 1 ) [ v] , access_avai 1 [ ] ; 
act_storem ( req_storera ( 1 1 ) [ V. m. q ] , access_avai I [ ] ) => 
storem_f or < 1 1 ) [ ] , s torem_activated[ v. m. q] ; 
per form_s torem ( storera_activated[ v. m. q] ) => 
storem_comp 1 eted [ ql ] ; 

f inish_storem(storem_compl etediql ] , s torem_f or ( 1 1 ) [ ] ) => 
avai 1 _storem( 1 1 ) [ql ], access_avai 1 [ ] ; 

When we look at the requirements of the register accesses 

we see that the above design for memory accesses is not 

suitable for register access if we want to allow for 

concurrent access to registers. So we have to find a way to 

express the properties of register accesses. Looking closely 

again at the requirements we realize that each register has 

the same access policies as the whole memory we specified 

before. This leads us to the fact that every register has to 

have its own specification. For the sake of simplicity let us 

say that our system has three registers with register 

addresses 1,2 and 3. We could now define three different nets 
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each for the access 



of a certain register. There is one 



problem though: whenever a register access is requested from 
somewhere in the system, the proper net for the register to 
be accessed has to be addressed. So we want to have the 
decision about which register net is meant centralized in one 
place in the system. Therefore we employ some decision 




Figure 5.1: Petri Net Graph for Memory Access 
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mechanism to select the right register access net. In this 
case the graph drawn out in Figure 5.2 of the net might 
confuse more than it helps. We try to specify the register 




Figure 5.2: Petri Net Graph for Register Access 
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access Just by direct reasoning. Still, the graph in Figure 
5.2 illustrates that, despite the fact that each register can 
be accessed independently from the other registers, only 
oneaccess to a register is allowed at a time because of the 
separate "access_avai 1 " places for each register. These 
places prohibit any access to a register until it is 
avai 1 ab 1 e. 

Again, we can anticipate that access to registers will be 
requested by several locations in the system. So we can state 
the entry and exit places as we have in the memory example. 
Next we already found out that there three independent 
register access nets and we can use again this structure for 
internal places and transitions we used in the memory access 
net. But how do we state that the net for register 1 is used 
when there is an access request for register 1 and only this 
net? The indication that a certain register is going to be 
accessed is the register address contained in the request 
message. Now instead of a name of the register address we 
state the actual value of it when we specify the properties: 
entry places 

req_f etchr ( net 1 abe 1 ) C re gad dr .state ] ; 
req_s torer <ne 1 1 abe 1 ) C va 1 . regaddr . state ] ; 

exit places 

avai 1 _f etchr < net 1 abe 1 ) C va 1 ] ; 
avai l_storer(netlabel )Cstate] ; 

internal places 

accessl_avai 1 C 1 ; 

f etchrl_acti vatedCregaddr . state] $ 
f etchr l_comp 1 etedC va 1 1 ; 

storer l_act i vated C va 1 . regaddr . state ] ; 
s torer l_comp 1 etedC state ] ; 
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access2_avai 1C]; 

f etch r2_act iva ted C regaddr .state ] ; 
f etchr2_compl eted C va 1 ] ; 
storer2_activatedCval . regaddr. state] ; 
storer2_coinp letedCstate] ; 

access3_avai 1C]; 

f etchr3_act I vatedC regaddr . state] ; 
fetchr3_completedCval ] ; 
storer3_acti vatedCval . regaddr. state] ; 
storer3_compl etedCstate] ; 

f etchr_f or (net 1 abe 1 ) C ] ; 
storer_f or (net 1 abe 1 ) C ] ; 

initial state 

=> access l_avai 1 C ] ; 

=> access2_avai 1 C ] ; 

= > access3_avai 1 C ] ; 

transi tions 

act_fetchrl: C regaddr . state] , C ] -> Cregaddr. state] , C ] ; 
perf orm_f etchr 1 : C regaddr . state] -> Cval]; 
f inish_f etchrl : Cval],C] -> Cval],C]; 
act_storerl; Cval . regaddr. state] , C ] -> 

Cval . regaddr. state] , C ] ; 

perf orra_storer 1 : C va 1 . regaddr . state ] -> Cstate]; 

f ini sh_storer 1 ; Cstate], C] -> Cstate], C]; 

act_fetchr2: C regaddr . state ], C ] -> C regaddr . state ], C ] ; 
perf orm_f etchr2 : Cregaddr. state] -> Cval]; 
f inish_fetchr2: Cval],C] -> Cval],C]; 
act_storer2: C va 1 . regaddr . state ], C ] -> 

Cval. regaddr. state], C] ; 

perf orm_storer2: C va 1 . regaddr . state ] -> Cstate]; 

f ini sh_s torer2 : Cstate], C] -> Cstate], C]; 

act_fetchr3: Cregaddr. state] , C ] -> C regaddr . state ], C ] ; 

perf orra_f etchr3 : C regaddr . state ] -> Cval]; 

f inish_fetchr3; Cval],C] -> Cval],C]; 
act_storer3: C va 1 . regaddr . state ], C ] -> 

Cval . regaddr. state] , C ] ; 

perf orm_storer3 : C va 1 . regaddr . state ] -> Cstate]; 
f inish_storer3: Cstate], C] -> Cstate], C]; 

properties 

act_f etchr 1 ( req_f etchr ( 1 1 ) C 1 . q ] , accessl_avai 1 C ] ) => 
fetch r_for( 11)C ], f etchr l_act i vatedC 1 . q ] ; 
per for m_f etchr 1 ( f etchr l_acti vatedC 1 . q] ) => 
f etchr l_compl etedC v] ; 

f ini sh_f etchr 1 ( fetchl_coinp 1 eted C V ] , f etchr_f or ( 1 1 ) C ] ) => 
avai l_fetchr(ll)Cv], accessl_avai 1C]; 
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act_storer 1 ( req_storer ( 1 1 ) [ V. 1 . q] , accessl_avai 1 [ ] ) => 
storer_for(ll)I], storerl_act i vated [ v. 1 . q 1 ; 
perf oriD_storerl ( storer l_acti vated [ v. 1 . q ] ) => 
storerl_compl etedCql]; 

f i nl sh_storer 1 ( storer l_comp letedCql], storer _for(ll)C]) 

= > aval 1 _storer ( 1 1 ) Cql ] , accessl_avai 1 [ ] ; 

act_f etchr2 ( req_f etchr ( 1 1 ) [ 2. q ] , access2_avai 1 C 3 ) => 
fetchr_for(ll)[], f etchr2_activatedC2. q3 ; 
perf oriB_f etchr2< f etchr2_activatedt2. q3 ) => 
f etchr2_completed[v3 ; 

f ini sh_f etchr2 ( f etch2_comp 1 etedC v3 , f etchr_f or ( 1 1 ) £ 3 ) => 
avai l_fetchr<ll)Cv3, access2_avai 1 £ 3 ; 
act_storer2(req_storer ( 1 1 ) £ V. 2. q3 , access2_avai 1 £ 3 ) => 
storer_for(ll)£3, s tore r2_acti vated £ v . 2. q3 ; 
perf orm_storer2 ( storer2_acti vatedE v. 2. q3 ) => 
storer2_comp 1 eted£ ql 3 ; 

f ini sh_storer2 ( s torer2_compl eted £ql3, storer _for(ll)£3) 

= > avai 1 _s torer ( 1 1 ) £ ql 3 , access2_avai 1 £ 3 ; 

act_f etchr3 ( req_f etchr ( 1 1 ) £ 3. q3 , access3_avai 1 £ 3 ) => 
fetchr_for(ll)£3, f etch r3_acti vated £3. q3 ; 
per f orni_f etchr3 ( f etchr 3_acti vated £3. q3 ) => 
f etchr3_corapl eted£ V 3 ; 

f ini sh_f etchr3( f etch3_comp 1 eted£ V 3 , f etchr_f or ( 1 1 ) £ 3 ) => 
avail _f etchr ( 1 1 ) £ v 3 , access3_avai 1 £ 3 ; 
act_storer3 ( req_storer ( 1 1 ) £ V. 3. q3 , access3_avai I £ 3 ) => 
storer_for(ll)£3, storer3_acti vatedE v. 3. q3 ; 
per form_s tore r3 ( s tor er3_acti vatedE v. 3. q3 ) => 
storer3_completed£ql 3 ; 

f ini sh_storer3 ( storer3_comp leted£ql3, storer_for(ll)£3) 

= > avai 1 _storer < 1 1 ) £ ql 3 , access3_avai I £ 3 ; 

We see that even specifications of simple resources 

become large and complex and the drawing the net is even more 

complex. Here we realize the real benefit of the introduction 

of subnets: once these subnets are specified we can use their 

properties everywhere in our system simply by stating the 

entry and exit places of the subnets in the net we want to 

specify. Those nets using subnets are actually extensions of 

the subnets. The next section will illustrate these facts in 

detai 1 . 
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C. MODELING OF INSTRUCTION FETCH AND EXECUTION TIMING 



From the static specification of the Abstract Processor 
we see that there are two operands "prog” and "exq" which are 
responsible for the process of executing programs. The 
process is kept going by corecursive calls between those two 
operators . 

Even though those two processes are very closely 
connected by corecursive calls we want to consider them 
separately and start with specifying the "exq" process. 

The "exq" process needs information about the instruction 
to be executed, the current memory address, and the state of 
the processor. After the process has finished it returns the 
new state. This determines the contents of the messages the 
entry and exit places of this net have to accommodate. Still 
we have to decide what kind of execution unit we want to 
specify. We want to specify that only one execution unit can 
be performed at a time. This means that we have to provide 
mutual exclusion for the use of this net. We can do this the 
same way as we provided for memory accesses. We can 
accomplish that by providing a distinct entry place and exit 
place indicated by netlabels. Now we are in a position to 
specify the entry and exit places: 

- req_jexq(net labe 1 > C instr. memaddr. state] { as the entry 

place 

- avai l_exq(net label ) Cmemaddr. state] { as the exit place 

At this point we have to look closely at the actions an 
execution on an instruction has to accomplish: retrieval of 
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information from the instruction, about register and memory 



addresses of operands. 


and 


about the 


operation 


to 


be 


performed, accesses to 


the 


operands , 


appl ication 


of 


the 



operator, and calculation of the address of the next 
instruction to execute. We see now that the previous 
specifications for memory and register accesses will come in 
handy when have to specify these accesses in the 
specification. Also we assume for this specification that 
there are nets for the retrieval of operands and operators 
from the instruction, the application of operands and 
calculation of the next memory address. 

The next issue we have to address is the fact that 
different instructions have to be executed differently. Here 
a decision mechanism similar to the one we introduced to 
access a specific register can help us to make the 
specification structured and understandable. The mechanism we 
introduce here has to recognize from the instruction part of 
the message which execution is requested and has to direct 
the path within the specification to the appropriate part of 
the specification. In the formal specification we indicate 
this explicitly by the contents of the instruction part of 
the request message. 

In the following we show some representative examples of 
the execution specifications of different Instructions. Their 
graphs are depicted in Figures 5.4 and 5.5 and illustrate 
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clearly the simplification obtained by the use of predefined 



subnets . 

entry places 

req_exq (net 1 abe 1 ) C instr . memaddr .state] ; 

exit places 

avai 1 _exq (net 1 abe I > C memaddr . state ] ; 

internal places 
exq_avai 1 C ) j 
exq_f or (net label ) C 3 ; 

exq_monad_activatedCstate] ; 
exq_monad_f etch [state] ; 
exq_monad_applyCstate] ; 
exq_monad_storeC 3 ; 

exq_mov_r_r_act i vatedC state 3 ; 
exq_mov_r_r_perform[ state 3 ; 
exq_mov_r_r_s toreC 3 ; 

initial state 

=> exq_availC3; 

transitions 

act i vate_exq_monad : C instr . memaddr. state] , C 3 -> 
[state], [instr], [instr], [instr], [ memaddr 3 ; 
star t_exq_monad : [ sta te 3 , [ regaddr 3 , -> 

[state], [regaddr. state] ; 

y_exq_monad : [ state 3 ,[ operator 3 ,[ va 1 3 -> 
[state] , [operator. va I 3 ; 
store_exq_monad : [state], [val 3, [regaddr] -> 

[], [val. regaddr. state]; 
f ini sh_exq_monad : [ 3 ,[ state 3 , [memaddr 3 -> 
[memaddr. state] ; 

acti vate_exq_roov_r_r : [ instr . memaddr . state 3 ,[ 3 -> 
[state], [instr], [instr], [memaddr 3 ; 
s tar t_exq_mov_r_r ; [ start 3 ,[ regaddr 3 -> 

[state] , [ regaddr. state] ; 
store_exq_raov_r_r : [ state 3 , [ regaddr 3 , [ va 1 3 -> 

[ 3 , [va 1 . regaddr. state 3 ; 
f ini sh_exq_mov_r_r : [ 3 , [ s ta te 3 , [memaddr 3 -> 
[memaddr. state] ; 

properties 

act i vate_exq_monad ( exq_avai 1 [ 3 , 

req_exq( 1 ) [ monad (o. rl.r2).m.q]> => 
exq_f or ( I ) [ 3 , exq_monad_act ivatediq] , 
req_operator ( 1 1 ) [ monad (o.rl.r2)3. 
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req_operandl ( 1 2) [ monad(o. rl . r2) ] , 
req_operand2( 13) [monad (o.rl.r2)l, 
req_nex tmemaddr < 1 4) Cm ] ; 
star t_exq_monad (exq_monad_act i vated C q] , 

aval l_operandl < 1 1 } C r 1 ] } •■> exq_monad_f etchC q ] , 
req_f etchr <I5)[rl.q3; 

app I y_exq_monad ( exq_monad_f etchC q3 , aval l_fetchr( 
aval l_operator < 1 1 ) C o ] ) => exq_monad_apply[ q] , 
req_appl y_mop( 16) Co. vl ; 
s tore_exq_monad (exq_roonad_app I y C q3 , 

aval 1 _app 1 y_mop( 1 6) [ vl 3 , aval 1 _operand2( 1 3) C r23 ) => 
exq_monad_storeC 3 , req_storer (17)Cvl.r2.q3; 
f ini sh_exq_monad ( exq_monad_storeC 3 , avai l_storer( 17)[ql3, 
avai 1 _nex tmemaddr ( 1 4 ) C ml 3 ) => avai 1 _exq< 1 ) Cml . ql 3 ; 

act i vate_exq_mov_r_r (exq_avai 1 C 3 , 

req_exq ( 1 ) [ mov_r_r <rl,r2).m.q3) => 
exq_mov_r_r_acti vated Cq3 , 
req_operandl ( 1 1) Cmov_r_r(rl, r2) 3, 
req_operand2( 1 2) C mov_r_r < r 1 , r2> 3 , 
req_nex tmemaddr ( 13) Cm3 ; 
s tar t_exq_mov_r_r (exq_mov_r_r_actl vatedC q 3 , 
avai l_operandl ( 1 1 ) [ rl 3 ) ~> 

exq_mov_r_r_per f ormC q3 , req_f etchr (14)Crl.q3; 
s tore_exq_roov_r_r (exq_mov_r_r_perf ormCq3 , 

avai l_f etchr ( 1 4) [ V 3 , avai 1 _operand2( 1 2) C r2 3 ) => 
exq_raov_r_r_s tore [ 3 , req_storer C v. r2. q3 ; 
f ini sh_exq_mov_r_r ( exq_mov_r_r_storeC 3, avail_storerCql3, 
avai l_nextmemaddr < 13) Cml 3 ) => 
avai l_exq( 1 ) Cml.ql3 ; 

The above two examples show the specification of the 
execution of a monadic instruction and of a move instruction. 



We have used the previously specified register access 
("fetchr" and "storer") to fetch the contents of a register 
and to store a value into a register. The way we used them 
was that we stated their entry and exit places at the 
appropriate locations in the description of the properties of 
our execution specification. In the same way we invoked the 
specifications of "nex tmemaddr” , "apply_mop”, ”operandl", 
"operand2" and "operator" which for this example we assumed 
to be defined . 
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We want to emphasize at this point that the stated 
properties of the given examples are hot the only way the 
execution could be specified: we are following the philosophy 
that as soon as the information is available, the possible 
requests are made based on the information. In a real 
specification other considerations may have priority, but our 
intention is to show how this can be accomplished using the 
methodo 1 ogy . 

The next part of the specification is to state the ”prog" 
part and to connect it with "exq” in a way that illustrates 
the corecursiveness of their interconnection. Since we have 
already modeled the **exq** part as a process taking an 
instruction, a memory address and the state, and provides a 
new memory address and a new state, we want this as a subnet 
in our "prog” specification. When we look again at the static 
specification of "prog” of the Abstract Processor we realize 
that this process needs a memory address and the state to get 
started, i.e. the same information as "exq" provides as 
output. This fact leads to the idea of a loop in requesting 
"prog": when "prog" has performed its initial tasks and has 
invoked "exq" it is in the situation of requesting itself 
again as soon as the result of "exq" is obtained. This idea 
will work nicely once the process is started, but how do we 
get this process running? Here we can claim that the initial 
request has to come from the outside world (imagine a 
possible implementation as an on-switch at the machine which 



61 



avail exq(ll) fml.gl] 




Figure 5.3: Partial Petri Net Graph of "exq_monad." 
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Figure 5.4: Partial Petri Net Graph of "exq_mov_r_r 
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exc^for (1) [] 



resets the state and sets the program counter to a predefined 

initial value). Ue want to specify this process as a single 

control unit and that this is the major process in the 

system. The following is a possible specification of "prog” 

(see also Figure 5.5): 

entry places 

req_prog [ memaddr . state ] ; 

internal places 
prog_avai 1 C 3 ; 

prog_f etchCmemaddr . state] ; 
prog_instrCmemaddr . state] ; 
prog_perf ormC ] 

initial state 

=> prog_avai I C ] ; 

transi t ions 

act i vate_prog t C ], Cmemaddr. state] -> 

[memaddr .state ] , [ memaddr .state ] ; 
ge t_i ns tr_prog ; [memaddr . state ], C va 1 ] -> 

[ memaddr . s tate ] , [ va I ] ; 
perf orm_prog : [memaddr . state ],[ ins tr ] -> 

[ ], [ instr. memaddr. state] ; 
finish_prog: [], [memaddr . state] -> 

[ ] , [memaddr. state] ; 

properties 

act i vate_prog ( prog_avai 1 [ ] , req_prog[m. q] ) *> 
prog_f etch[ m. q] , req_f etchm( 1 1 ) [m. q] ; 
get_instr_prog ( prog_act ivatedim.q], avail_fetchro( ll)[v]) 
=> prog_instr [m. q] , req_atomof instr ( 12) [ v ] ; 
perf orra_prog (prog_instr[m.q], 

avai l_atomof instr( 12) [ i ] ) => 
prog_perf orm[ ] , req_exq( 13)[i.m.q]; 
f i ni sh_prog ( prog_per f orm[ ] , avai 1 _exq[ml . ql ] ) => 
prog_avai I [ ] , req_prog[ml . ql ] ; 

The declaration of "req_prog" as an entry place models 

our previous stated connection to the outside world. Note 

that this specification in the form presented could not be 

used as a subnet since no exit place has been declared. The 
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following Figure 5.5 shows how this specification is drawn as 
a net. 

D. MODELING OF INTERRUPTS 

The above specifications of "exq** and "prog" and their 
interconnection in their current form does not provide for 
any recognition and processing of interrupts. This chapter is 
to show one way how interrupts could be handled using our 
specification methodology. 

As always the first step is to state the requirements for 
the process of interrupt handling. We want to look at 
interrupts as a signal which comes either from outside or 
inside the system on which the current running program is 
interrupted and a handler program at a predefined location is 
started. After the completion of the handler the execution of 
the interrupted program is resumed, therefore we need to save 
the memory address of the interrupted program. Also we want 
the invocation of the interrupt handler only to happen at a 
defined state, i.e. between the completion of the execution 
of one instruction and the fetching of the next instruction. 
Another requirement is that the interrupt handler acts on a 
single interrupt only one time, so that a following interrupt 
signal can be interpreted as another interrupt. In the 
following specification we assume that there is a dedicated 
stack in the system on which the current memory address of 
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Figure 5.5: 



Graph of 



”prog” without Interrupt Handling 
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the running program can be saved. Also, for simplicity 
reasons we allow only one type of interrupt, i.e. the handler 
has to determine the source of the interrupt by software. The 
following is one way to specify the above requirements (also 
see Figure 5.6) : 
entry places 

req_prog Cmemaddr . state] ; 

internal places 
prog_avai 1 C ] ; 

prog_f etchCmemaddr . state! j 
prog_i ns tr Cmemaddr .state] ; 
prog_per f orm C ] 
prog_checkCmemaddr . state! ; 
prog_saveC ! ; 

initial state 

= > prog_avai 1 C ! ; 

trans i tions 

act i vate_prog : C !, Cmemaddr . state ! -> 

Cmemaddr. state ! , C memaddr . state ! ; 
get_instr_prog : Cmemaddr . state !, C va 1 ! -> 

Cmemaddr . state ! , C va 1 ! ; 
perf orm_prog: Cmemaddr . state !, C instr ! -> 

C !, C ins tr . memaddr . state ! ; 
finish_progj C !, Cmemaddr . state] -> 

Cmemaddr . state!, C !; 

normal_prog: Cmemaddr . state! , C ! -> 

C ! , C memaddr . state!; 
i trpt_prog : Cmemaddr , state !, C ! -> 

C!, Cinstr. memaddr .state ! ; 
f in_int_prog t C !, Cmemaddr . state ! -> 

C ! , Cmemaddr . state ! ; 

properties 

activate_prog (prog_avai 1 C ! , req_progCm. q! ) => 

prog_f etchCm. q! , req_f etchmC 1 1 ) Cmemaddr . state! ; 
get_instr_prog(prog_activatedCm. q! , avai l_fetchm(ll)Cv!) 

=> prog_instr Cm. q! , req_atomof ins tr ( 1 2 ) C v ! ; 
perf orm_prog(prog_instr Cm. q! , 

avai l_atomof instr ( 1 2) C i ! ) => 
prog_perf ormC !, req_exq( 13) C i .m.q! ; 
f inish_prog(prog_perf ormC ! , avai 1 _exqCml . ql ! ) => 
prog_check C ml . ql ! , req_checkC!; 
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normal _prog ( prog_check Cml . ql 3 , aval 1 _norma 1 C 3 ) => 
prog_avai 1 C 3 , req_progCml . ql 3 
• i trpt_prog ( prog_check Cml . ql 3 , aval l_intrptC 3 ) »> 

prog_saveC 3 , req_exqC j sr ( int_addr ,sys_stk).ml.ql3; 
f in_int_prog(prog_saveC 3, aval l_exqCm2. q23 ) => 
prog_avai 1 C 3 , req_jprogCm2. q23 ; 

The above interrupt-sensitive specification of **prog" is 
very similar to the former specification of "prog” which did 
not provide for interrupt handling (compare Figure 5.5 and 
Figure 5.6). The major difference is that an "external agent" 
is invoked as soon as the execution of the instruction is 
completed. This Agent sends a message to one of its output 

places to show that either an interrupt is present or not. 

This construct ensures two properties: first, the External 

Agent is responsible for clearing the interrupt signal after 
it has recognized it so that an interrupt is only honored 
once; second, the presence of an interrupt has priority over 
the normal way of execution of a program. Once an interrupt 
has been detected by the Agent and its appropriate output 

place has been provided with a message the "prog” process can 

continue and it will place the current memory address on a 
specified system stack by executing a "push" instruction and 
will start a new cycle at the system interrupt handler 
address. Since the interrupt handler is by itself a loaded 
user program is responsible for saving the necessary register 
contents and for restoring those registers and the saved 
memory address from the system stack when it finishes. 
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prog_avall [ J 




Figure 5.6: Graph of "prog" with Interrupt Handling 
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E. EXECUTION OF PROGRAMS 



The question to be asked now is: how will the proposed 

specification methodology show the timing of the execution of 

programs? As an example, let us consider the following simple 

program: 

1000 : 1 
1001 : 2 

2000: M0V_M_R 1000, rl 

2001 : M0V_M_R 1001 , r2 

2002: ADD rl,r2,r3 

2003: M0V_R_M r3, 1002 

2004: STOP 

The above program retrieves the values ”1" and "2" from 
memory addresses 1000 and 1002 into registers "rl" and "r2", 
adds them together, with the result in "r3", and than moves 
this result into memory address 1002. At the top level of the 
specification there is the "prog" net. With the start of this 
program it receives the "req_progC2000. ql ] "• message from the 
outside. It retrieves the instruction contained in memory 
address 2000 and invokes the "exq" net with the message 
"req_exq[ instr . 2000. ql 1 " . Inside the "exq" net the "external 
agent" determines the appropriate net to process the 
instruction, here the "mov_m_r" net, and enters this net. 
After the completion of "exq", "prog" finishes with a message 
"req_progt 2001 . q2] " to itself where the "2001" and q2 were 
obtained from the execution of "exq". At this point "prog" 
starts all over again and finishes with the message 
"req__progC2002. q33 " . This repeats until the "stop" 

^Netlabels are omitted for simplicity 
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instruction is executed and results in 



termination of the 



process. Inside the invocations of the "exq" net there are 

several uses of the nets to access memory and registers as 

well as to process "nextraemaddr" . 

The following shows the major messages with their 

included data that are exchanged during the course of the 

execution of the program (not necessarily in the order as 

they might occur): 

req_progC2000, ql J 

req_f etchmC 2000, ql 3 
avai l_f etchmC "M0V_M_R 1000, rl" 3 
req_atomof instrC”MOV_M_R 1000, rl"3 
avai l_atomof instr [mov_m_r ( 1000, rl ) 3 
req_exqC mov_m_r ( 1000, r 1 ) . 2000. ql 3 
req_operandl Cmov_m_r ( 1000, rl ) 3 
avai l_operand2C 10003 
req_operand2[mov_m_r ( 1000, rl ) 3 
avai l_operand2C rl 3 
req_f etchmC 1000. ql 3 
avai 1 _f etchmC 1 3 
req_storer C 1 . r 1 . ql 3 
avai l_storer Cq23 
req_nextmemaddr C20003 
avai l_nextmemaddr C2001 3 
avai l_exqC2001. q23 
req_progC2001 , q2 3 

req_f etchmC 2001 , q23 
avai 1 _f etchmC "M0V_M_R 1001, r2" 3 
req_atoraof instr C "M0V_M_R 1001 , r2" 3 
avai 1 _atomof i nstr C mov_m_r (1001,r2)] 
req_exqCmov_m_r ( 1001 , r2) . 2001 . q2 3 
req_operandl Cmov_m_r < 1001 , r2) 3 
avai 1 _operand2C 10013 
req_operand2Cmov_m_r (1001, r2) 3 
avai 1 _operand2C r2 3 
req_fetchmC 1001. q23 
avai l_f etchmC 23 
req_storer C2. r2. q2 3 
ava i 1 _s torer C q3 3 
req_nextmemaddr C2001 3 
avai 1 _nextmemaddr C 20023 
avai l_exqC2002. q33 
req_progC2002. q33 

req_f etchmC2002, q33 
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aval l_fetchmC "ADD rl,r2,r3"] 
req_atomof instrC "ADD rl,r2,r3"] 
aval 1 __atomof instr Cdyadr (add, rl,r2,r3)] 
req_exqCdyad(add, rl, r2, r3) .2002. q33 
r eq__ope r and 1 C dyad ( add, rl,r2,r3)] 
aval 1 _operandl C r 1 3 
req__operand2C dyad (add, rl , r2, r3) ] 
aval 1 _operandl £ r2 3 
req_operand3 £ dyad (add, rl , r2, r3) 3 
aval 1 _operand3£ r 1 3 
req__operator £ dyad ( add, rl,r2,r3)3 
aval 1 _operator £ add 3 
req_f etchr £ r 1. q3 3 
aval l_fetchr£ 13 
req_f etchr £ r2. q33 
aval l_f etchr£23 
req_appl ydop£add. 1.23 
aval 1 _appl y_dop£33 
req_storer £3. r3. q3 3 
aval l_storer£q43 
req_nextmeinaddr £2002 3 
aval l_nextmemaddr £20033 
aval l_exq£2003. q4 3 
req_prog £2003, q4 3 

req_f etchm£2003, q43 
aval l_fetchm£"M0V_R_M r3,1003"3 
req_atomof instr £"M0V_r_m r3, 1003" 3 
aval l_atomofinstr£mov_r_m(r3, 1003) 3 
req_exq£mov_r_m( r3, 1003) . 2003. q43 
req_operandl £mov_r_m(r3, 1003) 3 
aval I _operand2£ r33 
req_operand2£mov_r_m( r3, 1003) 3 
aval l_operand2£ 10033 
req_f etchr £ r3 . q4 3 
aval l_fetchm£33 
req_storer £3. 1003. q43 
aval I_storer£q53 
req_nextmemaddr £20033 
aval l_nextmemaddr £20043 
aval l_exq£2004. q53 
req_prog £2004. q5 3 

req_f etchm£2004, q5 3 
aval l_fetchm£"ST0P"3 
req_atomof instr £ "STOP" 3 
avail _atomof instr £stop3 
req_exq£ stop. 2003. q4 3 
aval 1 _exq£ . q43 
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With the appropriate tools to track certain messages and 
their contents one is able to take snapshots during the 
course of the execution to determine the timing within the 
execution. 
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VI. SUMMARY AND CONCLUSION 



The intention of this work has been to present a 
methodology to specify timing in computer systems with strong 
emphasis on the issues of portability and reusability. The 
work has been also influenced by the goal to pursue a 
practical viewpoint for dealing with computer resources. In 
describing the essential properties of timing between 
abstracted computer resources, it has been possible to state 
the required timing in a system in an exact and rigorous way. 
As a first result of this work it has been pointed out that 
the attempt to specify the time behavior of a computer system 
without having a formal specification of the static behavior 
of the system will lead to inconsistencies and errors. We 
view the timing specification as an extension of the static 
specification (the system functionally) to a complete 
specification (the system functionally and dynamically). 

A. ADVANTAGES 

This methodology is based on Petri Nets and their 
underlying theory. Since Petri Nets are an accepted and 
commonly used tool in a variety of applications one familiar 
with Petri Nets will have almost no. problems understanding 
the methodology. During the course of this research a number 
of distinct advantages have been recognized: 
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1 . Ability to State Asynchronuous Timing 

Asynchronuous timing in a system is the most common 

timing method in any computer system, be it the reaction on 
the completion of some task or dealing with an external 
interrupt. The examples presented during this work show very 
clearly that every event displays asynchronuous timing since 
it reacts on certain holding conditions whenever they might 
be true. By stating events and their connected places we can 
describe the asynchronuous timing easily. 

2. Ability to Show Dataflow in a System 

The combined consideration of timing and dataflow in 
a system has been accomplished by changing the original token 
meaning of Petri Nets into a data carrying message. This 
enables the methodology to exhibit currently available data 
at any stage of the process. 

3. Ability to Model Concurrency 

The inherent ability of Petri Nets to model 
concurrency by activating several places as the result of a 
transition is available in this work and provides a useful 
construct . 

4. Ability to Model Mutual Exclusion 

As it was shown in different examples it was possible 
to model mutual exclusion simply by incorporating a structure 
of control places into nets which allow only one access to 
the nets or to of parts of the nets at a time. 
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B. DISADVANTAGES 



The disadvantages of this methodology can be based on the 
properties of Petri Nets and the intended accuracy of the 
specif i cat ions . 

1 . Comp 1 ex i tv 

The given examples, though very simple and small in 
their nature, exhibit a large complexity in stating the 
specification. This complexity is largely due to the details 
involved in the timing of systems and also to the attempt to 
handle data in the timing. The syntax presented is only one 
way of representing formal timing specification and it is 
very tedious for the user to deal with it, therefore a future 
implementation should provide an user interface which is easy 
to interact with, preferably in a graphical environment. 

2. Difficulty to Model Decisions 

Petri Nets by their nature are non-deterministic and 
so the specification methodology presented suffers from this 
disadvantage when we are forced to model decisions. The idea 
introduced of "external agents" helps to deal with this 
prob 1 em. 

C. FURTHER RESEARCH TOPICS 

This work has been a basic step in showing the 
possibility of specifying the time behavior of a computer 
Jsystem. As further research topics we suggest the following 
areas : 
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- Automation of this methodology to hide the complexity of 
the specification from the' user by providing a graphical 
interface 

- Provision of automated features which allow the user to 
make inquiries about the specified system, e.g. existence 
of deadlocks, history of invocations of certain subnets, 
trace of certain messages, etc. 

- Development of tools which are able to analyze and 
compare the performances of different specifications 

- Research in the area of timed Petri Nets where actions 
can be specified to be performed within a specified time 

- Application of this methodology in the area of the newly 
developed computer systems using transputers and their 
programming language OCCAM 
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APPENDIX A; EDITED STATIC SPECIFICATION OF 



THE ABSTRACT PROCESSOR 



This edited specification of an Abstract Processor is 
based on the work of Yurchak (1984). It uses an improved 
syntax of Davis and Yurchak (1985) which is considered more 
meaningful. Also, some minor changes to correct errors have 
been made. The specification consists of two parts; the 
replacement statement which provide a shortcut for stating 
frequently used properties, and the specification of the 
various resources. 



rep 1 ace ( X, S ) 

"equivrel (X,S) 

with 

"X( i , i ) = true( ) ; 

X(i, j) = X( j, i) ; 

impl ies(and(X( i , j ) , X( j , k) ) , X( i , k) ) = trueO;" 

replace ( X , S ) 

*'reflexive(x,S) 

with 

”X(i,i) = trueO;" 

rep I ace ( X, S ) 

"commutative ( X, S ) ; ” 

with 

”X(i, j) = X( j, i) 

rep 1 ace ( X, S ) 

”transitive(X,S) 

with 

"impl ies (and(X( i , j ) , X( j , k) ) , X( i , k) ) = trueO; 

rep 1 ace ( X, S ) 

"associative(X,S) 

with 

”X(i,X( j,k) ) = X(X( i , j ) , k) ; " 



replace ( X, S ) 

"irreflexive(X,S) ; 
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with 

"X(i, i) = falseO 

rep 1 ace ( X, S ) 

”symmetric(X,S) 

with 

”impl ies(X(i, j) ,X< j, i ) ) = trueO;" 

rep 1 ace ( X, S) 

”antisyraraetr ic(X, S ) 

with 

”irapl ies( and (X(i,j),X(j,i)), (i = = j)) 

replace(S,T) 

”idopers (S, T) ; ” 

with 

"star tT : -> S ; 

nextT: S -> S; 
pr evT : S - > S ; 
eqT: S, S -> bool ; ” 

replace (S, T) 

"idaxioras(S,T) 

with 

"prevS( star tT< ) ) is undefined; 
prevS(nextS ( i ) ) = i; 

if i ! = star tT ( ) 
then 

nex tS ( pr evS ( i ) ) = i; 

end i f ; 

equivrel (eqS,S) 

rep 1 ace ( S ) 

"typingopers (S) 

with 

"typeS: -> type; 
atomofS: va I -> S; 
valofS; S -> val;" 

rep 1 ace ( S) 

"typing ax ioms ( S ) ; " 

with 

"whattype ( va 1 of S ( t ) ) = typeS<); 

atomof S ( va 1 of S ( t ) ) = t; 

if whattype(v) = typeSC) 
then 

va 1 of S ( atomof S ( V ) ) = v; 

else 

atomofS(v) is undefined; 
end if;" 

replace (S, T) 



true ( ) ; " 
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"relop(S,T) 

with 

”app 1 yrop ( ST ( ) , V 1 , v2) = 

valofbool (TS(atomof S( vl) ,atomofS(v2) ) ) ; " 

replace (S) 

” i sops ( S ) ; " 

with 

”if whattype(v) = typeS() 
then 

app 1 ybop < i sS ( ) , V ) = va 1 of boo 1 ( true ( ) ) ; 

e 1 se 

app 1 ybop ( i sS <), V ) = va 1 of boo 1 ( f a 1 se ( ) ) ; 

end if;" 

replace (S, T) 

"stateaxioms(S,T) 

with 

”f etchSCa, ini tam( ) ) is undefined; 
stores ( f etchS (a, q) , a, q) = q;* 

imp 1 i es ( eqT ( al , a2) , f etchS ( al , stores ( V , a2, q ) ) = v) 
= true ( ) ; 

irapl ies(not(eqT(al,a2) , fetchS(al, storeS(v,a2, q) ) 
f etchS(al , q) ) = trueO;" 



Resource boolean is 

Extension of 

Operand Types 
boo 1 ; 

Operators 

true : - > boo 1 ; 

false: -> boo 1 ; 
not: bool -> bool; 
and: bool, bool -> bool; 

Derived Operators 

or: bool, bool -> bool; 
implies: bool, bool -> bool; 

Derived Definition 

or(bl,b2) = not < and ( not ( bl ) , not ( b2 ) ) ) ; 
imp 1 i es ( bl , b2) = not (and (bl , not (b2) ) ) ; 

Properties 

false = not(true()); 

not(not(b)) = b; 

and ( true (), b) = b; 

and ( f a 1 se ( ) , b) = false(); 
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commutative (and, boo 1 ) ; 



end boolean; 



Resource natural is 

Extension of 
boo 1 ean 



Operand Types 
nat ; 



Operators 

zeronat: -> nat; 

prednat: nat -> nat; 
succnat: nat -> nat; 
sumnat: nat, nat -> nat; 
mltnat: nat, nat -> nat; 
divnat: nat, nat -> nat; 
eqnat: nat, nat -> bool; 
gtnat: nat, nat -> bool; 



Derived Operators 



1 tnat : 


nat, nat -> 


boo 1 ; 


genat : 


nat, nat -> 


boo 1 ; 


1 enat : 


nat, nat -> 


boo 1 ; 


nenat : 


nat, nat -> 


boo 1 ; 



Derived Defini 
1 tnat ( n, m ) 
genat ( n, m ) 
1 enat (n , m) 
nenat (n, m) 



t i on 

= not ( or ( gtnat ( n, m 
= not ( 1 tnat ( n, m ) ; 

= not ( gtnat (n, m) ; 

= not ( eqnat ( n, m ) ; 



eqnat ( n , m ) ) ) 



Properties 

prednat ( zeronat () ) is 
prednat ( succnat ( n ) ) = 
succnat ( prednat ( n ) ) = 
sumna t ( n , zeronat () ) = 
sumnat (n, succnat (m) ) = 
subnat ( n , zeronat () ) = 

if gtnat(n,m) = true() 
then 



undef i ned ; 
n; 
n ; 
n; 

succnat ( sumna t ( n , m ) ) 
n ; 



f 



subnat ( n , succnat ( m ) ) = prednat ( subnat (n, m) ) 

e 1 se 



subnat (n, succnat (m) ) is undefined; 
end i f ; 

m 1 tnat ( X , zeronat () ) = zeronatC); 

m 1 tnat ( X , succnat ( zeronat ()) ) = x; 
mltnat(x,y) = sumnat ( x , m 1 tnat ( x , prednat ( y ))) ; 
if eqnat ( y, zeronat () ) = true() 
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then 



divnat(x,y) is undefined; 
else if ltnat(x,y) = true() 
then 

divnat(x,y) = zeronat; 

else 

divnat(x,y) = suranat < succnat ( zeronat () , 
d i vnat ( subnat < x , y ) , y ) ) ; 

end i f ; 
end i f ; 

eqnat(n,m) = eqnat ( succnat ( n ), succnat ( m )) ; 

gtnat ( succnat ( n ), n ) = true(); 

equivrel (eqnat, nat) ; 

irreflexive( gtnat, nat ) ; 

irreflexive< ltnat,nat) ; 

transitive( gtnat , nat ) ; 

trans i t i ve < 1 tnat , nat ) ; 

trans i t i ve ( genat , nat) ; 

trans i t i ve < 1 enat , nat ) ; 

ant i symme tr ic(genat,nat) ; 

anti symme tr i c ( 1 enat, nat ) ; 

symmetric(nenat, nat) ; 

commutat i ve ( sumnat , nat ) ; 

commutat i ve(mltnat,nat) ; 

associative( sumnat, nat ) ; 

associative(ml tnat, nat ) ; 

end natural ; 



Resource integer is 

Extension of 
boo 1 ean, 
natura 1 

Operand Types 
i nt ; 

Operators 

zeroint: -> int; 

ntoi : nat -> int ; 
iton: int -> nat; 

predint; int -> int; 
succint: int -> int; 

sumint: int, int -> int; 

mltint; int, int -> int; 
divint: int, int -> int; 

modint: int, int -> int; 

eqint: int, int -> bool; 

gtint: int, int -> bool; 
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Derived Operators 

Itint: int, int -> bool; 

geint: int, int -> bool; 

leint; int, int -> bool;, 

neint: int, int -> bool; 

Derived Definition 

ltint(n,m) = not ( or ( gt i nt ( n, tn ) , eq i nt ( n, m ) ) ) 
geint(n,m) = not ( 1 t int ( n, m ) ; 
leint(n,m) = not ( gtint (n, m) ; 
neint(n,m) = not ( eqint ( n, m ) ; 

Properties 

pred int ( succi nt (n ) ) = n; 

succi nt ( pred i nt ( n) ) = n; 

nto i ( zer ona t ( ) ) = zeroint(); 

nto i ( succnat ( n ) ) = 

suraint(succint(zeroint( ) ) , ntoi (n) ) ; 
i ton ( zeroi nt ( ) ) = zeronatC); 

if 1 1 i nt ( X , zero i nt ( ) ) = trueC) 

then 

iton(x) is undefined; 

else 

i ton ( succi nt ( X ) ) = sumnat( 

succnat ( zer ona t (),iton(x))); 

end i f ; 

if 1 1 i nt ( X , zeroi nt () ) = true() 

then 

absint(x) = subi nt ( zero int (), x ) ; 

else 

abs i nt ( X ) = x ; 
end i f ; 

sumi nt ( n , zer o i nt ( ) ) = n; 

sumint(n, succint(m) ) = succ int ( sum i nt ( n, m ) ) ; 

subint ( n , zero i nt ( ) ) = n; 

sub int (n, succ i nt ( m ) ) = pred int ( sub i nt ( n , m )) ; 

subi nt ( n , succi nt ( ra) ) is undefined; 
m 1 t i nt ( X , zero i nt ( ) ) = zerointC); 

m 1 t i nt ( X , succint ( zero i nt ( ) ) ) = x; 
mltint(x,y) = sum int ( x , m 1 1 i nt ( x , pred i nt ( y >)) ; 
if eqint (y, zeroint () ) = true() 
then 

divint(x,y) is undefined; 
else if 1 t i nt ( abs int ( X ) , abs int ( y ) ) = true() 
then 

divint(x,y) = zeroint; 
else if or( 

and (gtintCx, zeroint( ) ) , 
gtint(y, zerointC ) ) ) , 
and( ItintCx, zeroint( ) ) , 
ltint(y, zeroint( ) ) ) 

) = trueO 
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then 



divint(x,y) = sumint ( succi nt ( zer o i nt ( ) , 
divint ( subint ( x, y ) , y ) ) ; 

else 

divint(x,y) = sumint ( predint (zeroint () , 
divint(sumint(x,y),y) ) ; 

end i f ; 
end i f ; 
end i f j 

if gt int (m, zeroint ( ) ) = true() 
then 

if 1 tint (n, zeroint () ) = true() 
then 

modint(n,m) = modint ( sumint (n, m) , m) 

e 1 se 

modint(n,m) = subnatCn, 

m 1 tnat (m,divint(n,m))); 

end i f ; 

else 

modint(n,m) is undefined; 
end i f ; 

eqint(n,m) = eq i nt ( succi nt ( n ), succi nt ( m )) ; 

gt i nt ( succi nt ( n ), n ) = true(); 

equivrel (eqint, int) ; 

irreflexiveCgtint, int) ; 

irref lexive( Itint, int) ; 

transitive(gtint, int) ; 

tr ans itiveC Itint, int) ; 

transitive(geint, int) ; 

transitiveC leint, int) ; 

ant i symmetr i c ( ge i nt , int) ; 

antisymmetric( leint, int) ; 

symmetric(neint, int) ; 

commute t i ve ( sum i nt , int) ; 

commutativeCmltint, int) ; 

associat i ve ( sumint , int) ; 

associative(mltint, int ) ; 

end integer; 



Resource character is 

Extension of 
boo 1 ean 

Operands 
char ; 

Operators 

-> char ; 

'a','b’,’c',...,'z': -> char; 
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9 d; f 
9 ^ 9 


’ X’ 


9 /N 9 » jL 9 

9 9 “ 








-> 


char ; 




9 “ 9 












-> 


char ; 


» » • 


f 9 f 

char ; 


9 


9 • 9 ^ 








-> 


char ; 
















-> 


char ; 



NUL: -> char; 

SOH: -> char; 

STX: -> char; 

EXT: -> char; 

EOT: -> char; 

ENQ: -> char ; 

ACK: -> char; 

BEL; -> char; 

BS; -> char; 

HT: -> char; 

LF : -> char; 

VT : -> char ; 

FF : -> char; 

CR : -> char; 

SO: -> char; 

SI: -> char ; 

DLE : -> char ; 

DCl : -> char ; 

DC2 : -> char ; 

DCS: -> char; 

DC4 : -> char ; 

NAK: -> char; 

SYN; -> char; 

ETB : -> char; 

CAN : -> char ; 

EM: -> char; 

SUB: -> char; 

ESC : -> char ; 

FS: -> char; 

GS : -> char; 

RS : - > char ; 

US : - > char ; 

SP ; -> char; 

DEL : -> char ; 

eqchar; char, char -> bool; 
gtchar: char, char -> bool; 

Derived Operators 



1 tchar : 


char , char 


-> 


boo 1 ; 


gechar : 


char f char 


-> 


boo i ; 


1 echar : 


char , char 


-> 


boo 1 ; 


nechar : 


char , char 


-> 


boo 1 ; 



Derived Definition 

1 tchar ( n , m ) = not ( or ( gtchar < n, m ), eqchar ( n, m )) ) 

gechar(n,m) = no t ( 1 tchar ( n, m )) ; 
lechar(n,m) = not ( gtchar ( n, m )) ; 
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nechar ( n, m ) 



Properties 

gtchar (DLE, ’ ) 

gtchar 

gtchar ( ’ 

gtchar (’ 

gtchar z ’ ) 

gtchar ( ’ z’ , . . . ’ 

gtchar(’a’ , ’ ) 

gtchar (’ 

gtchar ^ ) 

gtchar 

gtchar 

gtchar 

gtchar ( ’ [ ’ , ’Z’ ) 

gtchar ( ' Z’ , . . . ’ 

gtchar ( ’ A’ , ’ ) 

gtchar 

gtchar < 

gtchar 

gtchar 

gtchar 

gtchar 

gtchar(’ : ’ , ’9’ ) 

gtchar ( ’ 9’ , . . . ’ 

gtchar ( ’ 0’ , ’ ) 

gtchar 

gtchar 

gtchar ( ’ 

gtchar 

gtchar 

gtchar 

gtchar 

gtchar ( ’ 

gtchar ( ’ ’ ’ , ’ 8cM 

gtchar 

gtchar 

gtchar 

gtchar (’ #’ , ’ ) 
gtchar 

gtchar ( ’ ! ’ , SP ) 
gtchar (SP, US) = 
gtchar (US, RS) = 
gtchar (RS, GS) = 
gtchar (GS, FS) = 
gtchar (FS, ESC) 
gtchar (ESC, SUB) 
gtchar(SUB, EM) 
gtchar (EM, CAN) 
gtchar (CAN, ETB) 



= not (eqchar (n, m) ) 



= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

’ ) = true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 
true ( ) ; 
true ( ) ; 

= true ( ) ; 

/ ) = true ( ) ; 
= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

’ ) = true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 

= true ( ) ; 
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true ( ) ; 
true ( ) ; 
true ( ) ; 
true ( ) ; 

true ( ) ; 

= true ( ) ; 
true ( ) ; 
true ( ) ; 

= true ( ) ; 



86 



gtchar (ETB, SYN) = true(); 
gtchar (SYN, NAK) = true(); 
gtchar (NAK, DC4) = trueO; 
gtchar ( DC4 , DCS ) = true(); 
gtchar (DCS, DC2) = true(); 
gtchar(DC2,DCl) = trueO; 
gtchar (DCl , DLE) = true(); 
gtchar ( DLE, S I ) = true(); 
gtchar ( S [, SO ) = true(); 
gtchar ( SO , CR ) = true(); 
gtchar (CR, FF) = true(); 
gtchar(FF, VT) = trueO; 
gtchar ( VT, LF ) = true(); 
gtchar (LF, HT) = true(); 
gtchar (HT, BS ) = true(); 
gtchar (BS , BEL) = true(); 
gtchar ( BEL, ACK ) = true(); 
gtchar (ACK, ENQ) = true(); 
gtchar ( ENQ, EOT ) = true(); 
gtchar (EOT, ETX) = true(); 
gtchar (ETX, STX) = trueO; 
gtchar ( STX , SOH ) = true(); 
gtchar (SOH, NUL) = trueO; 
equivrel ( eqchar , char ) ; 
irreflexive(gtchar,char) ; 
transitive(gtchar, char) ; 
irref lexive( 1 tchar, char ) ; 
trans itive( 1 tchar, char) ; 
transitive(gechar, char) ; 
transitive( lechar) char ) ; 
anti symme tr i c(gechar,char) 
ant i symmetr ic( lechar, char) 
symmetr ic (nechar ) ; 



end ; 



Resource s tr ing ( e 1 e 1 ment ) is 

Parameter element is 

Extension of 
boo 1 ean 

Operands 
1 m ; 

Operators 

eq 1 m : lm,lm -> bool; 

gtlm: lm,lm -> bool; 

Derived Operators 
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Itlra: lra,Im -> boo 1 ; 

ge I m : 1 m , 1 m -> boo 1 ; 

1 e 1 m ; 1 m, 1 m -> boo 1 ; 

nelm: lm,lra -> bool; 

Derived Definition 

ltlra(n,ra) = not ( or ( gt 1 m ( n , m ) , eq 1 m ( n, m ) ) ) 
gelm(n,m) = not ( 1 t 1 m(n, m) ) ; 

Ielm(n,m) = not ( gt 1 ra (n, ra) ) ; 
nelm(n,m) = not ( eq 1 m ( n, m ) ) ; 

Properties 

equivrel (eqlm, Ira) ; 
irreflexiveCgtlra, Ira); 
transitiveCgtlra, Ira) ; 
irreflexiveCltlra, Ira); 
transitive( Itlra, Ira) ; 
trans itiveCgelra, Ira) ; 
trans itive( lelra) Ira) ; 
ant i syraraetr ic ( ge 1 ra, Ira); 
anti syraraetr ic(lelra,Ira); 
syraraetr i c ( ne 1 m ) ; 

Extension of 
natura 1 ; 
boo 1 ean ; 

Operands 

s tr . Ira; 

Operators 

nullstr.lra: -> str.lra; 
raakestr . 1 ra : Ira -> str.lra; 

lenstr.lra: str.lra -> nat; 
headstr.lm: str.lra -> Ira; 

tailstr.Ira: str.lra -> str.lra; 

catstr.lra: s tr . 1 ra, s tr . 1 m -> str.lra; 
eqstr.lra: s t r . 1 m , s tr . 1 m -> bool; 
gtstr.lra: s tr . 1 ra, s t r . 1 ra -> bool; 

Derived Operators 

Itstr.lra: str . 1 ra, str . 1 ra -> bool; 
gestr.lra: str . 1 m, str . 1 ra -> bool; 
lestr.lra: s tr . 1 ra , s t r . 1 ra -> bool; 

nestr.lra: s tr . 1 m, s tr . 1 ra -> bool; 

Derived Definition 
ltstr.lra(n,ra) = 

not(or(gtstr. lra(n,ra),eqstr. lra(n,ra))); 
gestr . 1 ra (n, ra ) = not ( 1 tstr . 1 ra(n, m) ) ; 

1 est r . 1 m ( n , ra ) = not ( gtstr . 1 ra ( n, ra ) ) ; 

nestr . 1 m ( n, ra) = not ( eqstr . 1 ra ( n, ra ) ) ; 

Properties 



88 



1 enstr . 1 m ( nu 1 1 s t r . 1 m ( ) ) = zeronat(); 

1 ens tr . 1 m ( makestr . 1 m ( 1 ) ) = succnat ( zeronat ( ) ) 
1 enstr . 1 m ( cats tr . 1 m ( s 1 , s2) ) = 

sumnat ( lenstr. Im(sl), lenstr. Im(s2) ) ; 
heads tr . 1 m ( makes tr . 1 m ( 1 ) ) = 1; 

tai 1 str . lm(makestr . lm( 1 ) ) = nu 1 1 str . 1 m ( ) ; 
heads tr . 1 m ( catstr . 1 m ( makes tr . 1 m ( 1 ), s ) ) = 1; 

tai 1 str . 1 m ( cats tr . 1 m ( makestr . 1 m ( 1 ), s ) ) = s; 
heads tr . 1 m ( nu 1 1 str . 1 m () ) is undefined; 
ta i 1 s tr . 1 m ( nu 1 1 s tr . 1 m ( ) ) = nu 1 1 str . 1 m ( ) ; 
cats tr . 1 m ( cats tr . 1 m ( s 1 , s2 ), s3 ) = 

catstr. Im(sl, catstr. Im(s2,s3)) ; 
cats tr . 1 m ( nu 1 1 str . 1 m <), s ) = catstr. lm( 
s,nullstr.lm()) = s; 

implies(eqlm(ll, I2),eqstr. lm( makestr. Im(ll), 
makes tr . 1 m ( 1 2 ) ) ) = trueC); 
implies(gtlm(ll, 12),gtstr. lm( makestr. Im(ll), 
makes tr . 1 m ( 1 2 ) ) ) = true(); 
gtnat( lenstr. lm( makestr . 1 m ( 1 ) , 

1 enstr . 1 m ( nu 1 1 str . 1 m <) ) = true(); 
imp 1 i es ( g tnat (lenstr. Im(sl), lenstr. Im(s2)), 
gtstr . 1 m ( s 1 , s2 ) = true(); 
if 1 ens tr . 1 m ( s 1 ) != zeronat() 

then 

gtnat(lenstr. lm( catstr. Im(sl,s2), 

1 enstr . 1 m ( s2 ) = true(); 

else 

eqnat (lenstr. lm(catstr. Im(sl,s2), 

1 enstr . 1 m ( s2 ) = true(); 
endi f ; 

equi vre l(eqstr. lm,str. Im); 
irreflexive(gtstr. lm,str. Im); 
transitive(gtstr. lm,str. Im); 
irreflexive(ltstr. Im.str. Im); 
trans itive(ltstr. lm,str. Im); 
transi tive(gestr. lm,str. Im) ; 
transitive(lestr. lm)str. Im); 
ant i symmetr i c ( gestr. lm,str. Im); 
anti symmetr i c(lestr. lm,str. Im); 
symmetr i c ( nes tr . lm,str. Im); 

end s tr ing ( e 1 eraent ) ; 



Resource str ing ( character ) is 

where 

Ira = char; 

nullstr.char = nullstr.lm; 
makestr. char = makestr. Im; 
len.char = lenstr. Im; 
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head. char = headstr.lm 
tail. char = tailstr.lm 
cat. char = catstr.lm; 
eq.char = eqstr.lm; 
gt.char = gtstr.lm; 

1 t. char = 1 tstr « Im ; 

ge.char = gestr.lm; 
le.char = lestr.lm; 
ne.char = nestr.lm; 

end s tr i ng < character ) ; 



Resource identifiers is 

Extension of 
boo 1 ean 

Operands 
memid ; 
r e g i d ; 
stk id ; 
fid; 

Operators 

i doper s ( mem i d , memsem ) ; 
idopersC redid, regseg) ; 
i dopers (stkid, stkseg) ; 
idopersCfid. fseg) ; 

Properties 

idaxiom(memid,memseg) ; 
idaxiomCregid, regseg) ; 
idaxiom (stkid, stkseg) ; 
idaxiomCfid, fseg) ; 



end ; 



Resource memaddress is 

Extension of 

i dent i f i er s , 
boo 1 ean 



Operands 

memaddr ; 

Operators 

s tar tmemaddr : memid -> 
nextmemaddr: memaddr - 
prevmemaddr: memaddr - 



memaddr ; 
memaddr 
memaddr 
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getmemid; memaddr -> memid; 
offset: int, memaddr -> memaddr; 

eqmemaddr; memaddr , memaddr -> bool; 

Properties 

prevmeraaddr ( star tmemaddr ( i ) ) is undefined; 
prevmemaddr (nextmemaddr (m) ) = m; 
nextmemaddr < prevmemaddr (m) ) = m; 

of f set (succint (n) , m) = nex tmemaddr ( of f set ( n, m )) ; 

if offset(n,m) = star tmemaddr ( ) 

then 

of f set ( predint ( n ), m ) is undefined; 

else 

of f set ( pr ed i nt ( n) , m ) = prevmemaddr ( of f set ( n , m ) ) 
endi f ; 

eqmemid(i, get mem id(offset(n,startmemaddr(i)))) = 
true ( ) ; 

eqmemaddr ( star tmemaddr ( i 1 ) , star tmemaddr ( i2) ) = 
eqmemid ( i 1 , i2) ; 

eqmemaddr ( star tmemaddr ( i ), nextmemaddr (a ) ) = false() 

eqmemaddr (nextmemaddr(al),nextmemaddr(a2) ) = 

eqmemaddr ( al , a2 ) ; 
of f se t ( zero int ( ) , m ) = m; 
eqivrel ( eqmemaddr , memaddr ) ; 

end memaddress ; 



Resource regaddress is 

Extension of 

ident i f iers, 
boolean 

Operands 

regadd r ; 

Operators 

star tregaddr : regid -> regaddr; 

nextregaddr: regaddr -> regaddr; 
prevregaddr; regaddr -> regaddr; 
getregid: regaddr -> regid; 
eqregaddr: regaddr , regaddr -> bool; 

Proper t i es 

prevregaddr (star tregaddr ( i ) ) is undefined; 
prevregaddr ( nex tregaddr ( m ) ) = m; 
nex tregaddr ( prevregaddr ( m ) ) = m; 

eqregaddr(startregaddr(il),startregaddr(i2)) = 
eqregid ( i 1 , i2) ; 

eqregaddr ( startregaddr ( i ), nextregaddr (a) ) = false() 
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eqregaddr(nextregaddr(al) ,nextregaddr(a2) ) = 

eqregaddr(al,a2) ; 

eqivrel (eqregaddr, regaddr) ; 

end regaddress; 



Resource stkaddress is 

Extension of 

i dent i f i ers , 
boo 1 ean 



Operands 

stkaddr ; 

Operators 

getstkid: stkaddr -> stkid; 
eqstkaddr: stkaddr , atkaddr -> bool; 

Properties 

eqstkaddr(nextstkaddr(al),nextstkaddr(a2)) = 
eqstkaddr(al,a2) ; 
equi vre 1 (eqstkaddr, stkaddr) ; 

end stkaddress ; 



Resource files is 

Extension of 

i dent i f i ers , 
boo 1 ean 

Operands 

file; 

Operators 

getfile: fid -> file; 

eqfile: file, file -> bool; 

Properties 

eqf i 1 e ( getf i 1 e ( i 1 ) , getf i 1 e ( i 2 ) ) = eqf i 1 e ( i 1 , i2) 
equivrel (eqfi le, fi le) ; 

end files; 

Resource operatorc 1 asses is 
Extension of 
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Operands 
mop ; 
dop; 
top; 
qop; 
sop; 
oop; 
rop; 
bop; 

Operators 

Properties 

end operatorc 1 asses ; 
Resource instruct! ontype is 

Extension of 

Operands 

instr ; 

Operators 

Properties 
end intructiontype ; 

Resource typing is 

Extension of 
boo 1 ean ; 
natura 1 ; 
integer ; 
character ; 
str i ng ( character ) ; 
identi f iers ; 
memaddr ess ; 
regaddress ; 
stkaddr ; 
files; 

operatorc I asses; 
intructiontype; 

Operands 
type; 
va 1 ; 

Operators 

typingopers(bool ) ; 
typi ngopers ( nat ) ; 
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typingopers ( int ) ; 
typingopers (char ) ; 
typingopers(str.char) ) ; 
typingopers (memid ) ; 
typingopers ( regid) ; 
typi ngoper s ( s tk i d ) ; 
typingopers(fid) ; 
typingopers (memaddr ) ; 
typingopers ( regaddr ) ; 
typingopers ( stkaddr ) ; 
typingopersCfi le) ; 
typingopers (mop ) ; 
typingopers (dop) ; 
typingopers ( top) ; 
typingopers ( qop) ; 
typi ngoper s ( sop ) ; 
typingopers (oop) ; 
typingopers ( rop ) ; 
typingopers (bop) ; 
typingopers (instr) ; 

whattype: va 1 -> type; 

eqtype: type, type -> bool; 

Properties 

typingaxiom(bool ) ; 
typ i ngax i om ( nat ) ; 
typingaxiom( int) ; 
typingaxiom(char) ; 
typingax i om ( str . char ) ; 
typi ngax i om ( mem i d ) ; 
typingax iom( regid) ; 
typingaxiom(stkid) ; 
typingaxiom(fid) ; 
typingaxiom(memaddr ) ; 
typi ngax i om ( regadd r ) ; 
typingax iom( stkaddr ) ; 
typingaxiom(fi le) ; 
typ i ngax i om ( mop ) ; 
typingax iom (dop) ; 
typi ngax i om ( top ) ; 
typingax iom ( qop) ; 
typi ngax i om ( sop ) ; 
typingaxiom(oop) ; 
typingaxiom(rop) ; 
typ i ngax i om ( bop ) ; 
typingaxiom( instr) ; 
equi vrel ( instr ) ; 

end typing; 
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Resource operators is 

Extension of 

opera to rc 1 asses , 
typing 

Operands 

Operators 

boolnot: -> mop; 
booland: -> dop; 
boolor: -> dop; 

natpred: -> mop; 

natsucc: -> mop; 

natsum; -> dop; 
natsub: -> dop; 
nateq: -> rop; 
natgt: -> rop; 

natlt: -> rop; 
intpred: -> mop; 

intsucc: -> mop; 

intabs: -> mop; 

intntoi : -> mop ; 

intiton: -> mop; 
intsum: -> dop; 
intsub: -> dop; 

intmlt: -> dop; 
intdiv: -> dop; 

intmod: -> dop; 

inteq: -> rop; 

intgt: -> rop; 

int 1 t : -> rop ; 

chareq: -> rop; 

chargt: -> rop; 

charmakestr: -> mop 

charstrlen: -> mop; 

charheadstr: -> mop 

chartailstr: -> mop 

charcatstr: -> dop; 

str. chareq: -> rop; 

str. chargt: -> rop; 

i sboo 1 : -> bop ; 

isnat: -> bop; 
isint : -> bop; 
ischar: -> bop; 

isstr.char: -> bop; 

ismemid: -> bop; 
isregid: -> bop; 

isstkid: -> bop; 

i sf id : -> bop ; 

ismemaddr: -> bop; 

isregaddr: -> bop; 




Properties 

applymop(boolnot( ) , v) = valofbool (notCatomofbool (v) ) 
applydop(booland(),vl,v2) = valofbool ( 
andCatomofbool (vl),atomofbool (v2) ) ; 
applydopCboo lor(),vl,v2) = valofbool ( 
or(atomofbool (vl),atomofbool (v2) ) ; 
app 1 ymop( natpred ( ) , V ) = valofnatC 

prednat(atomofnat(v) ) ; 
app 1 ymop ( nat succ ( ) , V ) = valofnatC 

succnat(atomofnatCv) ) ; 
applydop(natsum(),vl,v2) = valofnatC 

sumnat Catomof nat Cvl) ,atomofnatCv2) ) ; 
applydopCnatsubC),vl,v2) = valofnatC 

subnatCatomofnatCvl) , atomof nat C v2) ) ; 
app 1 ymop C i ntpr ed C ) , V ) = valofintC 

predintCatomofintCv) ) ; 
app 1 ymop C i ntsucc C ), V ) = valofintC 

succi nt CatomofintCv) ) ; 
applymopC intabs C ), v) = valofintC 
absintCatomofintCv) ) ; 
applymopC intntoi C ), v) = valofintC 
ntoiintCatomofintCv) ) ; 
app I ymop C in t i ton C ) , V ) = valofintC 

itonintCatomofintCv) ) ; 
applydopCintsumC),vl,v2) = valofintC 

sumintCatomofintCvl) ,atomofintCv2) ) ; 
applydopC in t sub C),vl,v2) = valofintC 

subintCatomofintCvl),atomofintCv2) ) ; 
applydopCintmltC),vi,v2) = valofintC 

mltintCatomofintCvl) ,atomofintCv2) ) ; 
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app lydop( intdiv ( ) , vl , v2) = valofint( 

divint(atomofint(vl),atomofint(v2) ) ; 
app 1 ydop ( intmod ( ) , vl , v2) = valofint( 

mod int ( atomof int ( vl ) , a tomof int ( v2) ) ; 
app 1 ymop ( chars tr 1 en (), V ) = valofnat( 
lenstr. char(atomofstr. char(v) ) ) ; 
app 1 ymop ( charmakes tr (), V ) = va 1 of str . char ( 

makes tr . char (atomof char ( v ) ) ) ; 
app 1 ymop (char heads tr (), V ) = valofchar( 
head str. char (atomofstr. char (v) ) ) ; 
app 1 ymop (char tai 1 str (), V ) = va 1 of s t r . char ( 

tai 1 str . char (atomofstr. char ( v ) ) ) ; 
app 1 ydop ( charcats tr ( ) , vl , v2) = va 1 of s tr . char ( 
catstr. char(atomofstr. char(vl) , 
atomofstr. char ( v2) ) ) ; 
re 1 op(nat, eq) ; 
re 1 op ( nat , gt ) ; 
re 1 op ( nat , It); 
r e 1 op ( i nt , eq ) ; 
re 1 op( int, gt ) ; 
re 1 op (int, It) ; 
re 1 op ( char , eq ) ; 
re 1 op ( char , g t ) ; 
relop(str.char,eq) ; 
relop(str. char , g t ) ; 
i sops ( boo 1 ) ; 
i sops ( nat ) ; 
i sops (int) ; 
i sops (char ) ; 
isops(str.char) ; 
isops (memid) ; 
isops(regid) ; 
i sops ( s tk i d ) ; 
isops(fid) ; 
isops (memaddr ) ; 
isops(regaddr) ; 
isops(stkaddr) ; 
isops (file) ; 
i sops (mop) ; 
isops ( dop ) ; 
isops ( top ) ; 
isops ( qop ) ; 
isops (sop) ; 
i sops (oop ) ; 
isops ( r op ) ; 
isops (bop ) ; 
isops ( instr ) ; 



end operators; 
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Resource intructions is 



Extension of 
nature 1 , 
integer , 
memaddress , 
regaddress , 
s tkaddress , 
operatorc 1 asses , • 
in true t i on type , 
typing 

Operands 

Operators 

or g : -> instr ; 
extern: instr; 

g 1 ob 1 : -> instr ; 
rabegin : -> instr ; 
mend : -> instr ; 

offst: int,regaddr -> instr; 

link: regaddr,nat -> instr; 

unlink: regaddr -> instr; 
monads: mop, regaddr *> instr; 
monad: mop, regaddr , regaddr instr; 

monadi: mop, va 1 , regaddr -> instr; 
dyads: dop, regaddr , regaddr ~> instr; 
dyadsi: dop, va 1 , regaddr -> instr; 
dyad: dop, regaddr , regaddr , regaddr -> instr; 

dyadi: dop, va 1 , regaddr , regaddr -> instr; 
triads: top , regaddr , regaddr , regaddr -> instr; 

triads!: top, va 1 , regaddr , regaddr -> instr; 

triad: top, regaddr, regaddr, regaddr, regaddr -> instr; 

triad!: top, va 1 , regaddr , regaddr , regaddr -> instr; 

quads: qop, regaddr, regaddr, regaddr, regaddr -> instr; 

quad : qop, regaddr, regaddr, regaddr, 
regaddr , regaddr -> instr; 
sexads: sop, regaddr, regaddr, regaddr, 
regaddr , regaddr , regaddr -> instr; 
sexad: sop, regaddr, regaddr, regaddr, regaddr , 

regaddr , regaddr , regaddr -> instr; 
octads: oop, regaddr, regaddr, regaddr, regaddr, 

regaddr, regaddr, regaddr, regaddr -> instr; 
octad: oop, regaddr, regaddr, regaddr, regaddr, 

regaddr,regaddr, regaddr, regaddr, regaddr -*> instr 
movi_m: val,memaddr -> instr; 

movi_pcr: val,int -> instr; 
movi_r: val, regaddr -> instr; 
movi_ri: val, regaddr -> instr; 
movi_rid: va 1 , regaddr , int -> instr; 
movi_ridn: va 1 , regaddr , nat , i nt -> instr; 
mov_m_m: memaddr , memaddr -> instr; 
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mov_m_r ; memaddr, regaddr -> instr; 
mov_tn_ri: memaddr , regaddr -> instr; 
mov_m_rid: memaddr , regaddr , int -> instr; 
mov_m_ridn: memaddr , regaddr , nat , int -> instr; 
mov_pcr_pcr : int, int -> instr; 

mov_jpcr_r: int, regaddr -> instr; 

mov_pcr_ri: int, regaddr -> instr; 

mov_pcr_rid: int , regaddr , int -> instr; 

mov_pcr_r idn : int, regaddr , nat, int -> instr; 

mov_r_m: regaddr , memaddr instr; 
mov_r_pcr: regaddr, int -> instr; 

mov_r_r: regaddr , regaddr -> instr; 
mov_r_ri: regaddr , regaddr -> instr; 

mov_r_rid: regaddr , regaddr , int -> instr; 

mov_r_ridn; regaddr , regaddr , nat , int -> instr; 
mov_ri_m: regaddr , memaddr -> instr; 
mov_ri_pcr; regaddr, int -> instr; 
mov_ri_r; regaddr , regaddr -> instr; 
mov_ri_ri: regaddr , regaddr -> instr; 

mov_ri_rid: regaddr , regaddr , int -> instr; 
mov_ri_ridn: regaddr, regaddr , nat, int -> instr 

mov_rid_m; regaddr , i nt , memaddr -> instr; 
mov_rid_pcr: regaddr, int, int -> instr; 

mov_rid_r; regaddr , int , regaddr -> instr; 
mov_rid_ri: regaddr , int , regaddr -> instr; 
mov_rid_rid: regaddr , int, regaddr , int -> instr 
mov_r id_r i dn ; regaddr , int , regaddr , nat , int -> 
mov_ridn_m; regaddr , nat , int , memaddr -> instr; 
mov_r i dn_pcr : regaddr , nat, int, int -> instr; 
mov_ridn_r; regaddr , nat , int , regaddr -> instr; 
mov_ridn_ri: regaddr , nat, int, regaddr -> instr 

mov_r idn_r id : regaddr , nat, int, regaddr , int -> 
mov_r i dn_r idn: regaddr, nat , int, regaddr, nat, 
int -> instr ; 

push_i : val,stkaddr -> instr; 

push_m: memaddr , s tkaddr -> instr; 

push_pcr: int,stkaddr -> instr; 

push_r: regaddr , stkaddr -> instr; 

push_ri: regaddr , s tkaddr -> instr; 

push_rid: regaddr , int, stkaddr -> instr; 

push_ridn; regaddr , nat, int, stkaddr -> instr; 

pop_x : stkaddr -> instr; 

pop_m: stkaddr , memaddr -> instr; 

pop_pcr ; stkaddr, int -> instr; 

pop_r: stkaddr , regaddr -> instr; 

pop_ri: stkaddr , regaddr -> instr; 

pop_rid: stkaddr , regaddr , i nt -> instr; 

pop_ridn: stkaddr , regaddr , nat, int -> instr; 

nop: -> instr; 

stop: -> instr; 

jmp: memaddr -> instr; 

jmp_i : memaddr -> instr; 



instr ; 



instr ; 
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jmp_r: regaddr -> instr; 

bra: int -> instr; 

bra_r: regaddr -> instr; 

if: re 1 op, regaddr , regaddr , memaddr -> instr; 

ifi: re 1 op, regaddr , va I , memaddr -> instr; 

ifte: relop, regaddr, regaddr, memaddr , memaddr -> instr 

iftei: r e 1 op, regadd r , va 1 , memadd r , memaddr -> instr; 

if_pcr: re 1 op, regaddr , regaddr , int -> instr; 

ifi_pcr: re 1 op, regaddr , val , int -> instr; 

ifte_pcr: re 1 op, regaddr , regaddr , int, int -> instr; 

iftei_pcr: r e 1 op, regaddr , va 1 , int , int -> instr; 

test: bop, regaddr , memaddr -> instr; 

testm: bop, memaddr , memaddr -> instr; 

teste: bop, regaddr , memaddr , memaddr -> instr; 

testme: bop, memaddr , memaddr , memaddr -> instr; 

test_pcr: bop, regaddr , int -> instr; 

testm_pcr: bop, memaddr , in t -> instr; 

teste_pcr: bop, regaddr , int , int -> instr; 

testme_pcr: bop, memaddr , int , int -> instr; 

jsr: memaddr , stkaddr -> instr; 

jsr_i: memaddr , stkaddr *> instr; 

jsr_r: regaddr , stkaddr -> instr; 

bsr: int, stkaddr -> instr; 

bsr-r: regaddr , stkaddr -> instr; 

rts: stkaddr -> instr; 

open: stkaddr -> instr; 

close: stkaddr -> instr; 

read: stkaddr -> instr; 

write: stkaddr -> instr; 

Properties 
end intructions; 



Resource amstate is 

Extension of 
boo 1 ean , 
natural , 
integer , 
str(character) , 
memaddr ess , 
regaddress , 
f i 1 es , 

ident i f ier s , 
typing 

Operands 
state ; 

Operators 
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f etchm : 


memaddr , s tate 


-> va 1 ; 


f e tchr : 


regaddr , state 


-> va 1 ; 


storem ; 


va 1 , memaddr , s tate -> state; 


s torer : 


va 1 , regaddr , state -> state; 


ini tarn ; 


-> state; 




initstk: 


stkaddr , state 


-> state; 


topstk : 


stkaddr, state 


-> va 1 ; 


pushstk : 


va 1 , stkaddr , state -> state; 


popstk : 


stkaddr , state 


-> state; 


1 a 1 1 oc : 


nat, state memid; 


Ifree: memid, state -> 


state ; 


indir: nat, memaddr -> 


memaddr ; 


i nf i 1 e : 


file, state -> 


va 1 ; 


outf i 1 e ; 


va 1 , f i 1 e , state -> state; 


openf i 1 e 


: s tr . char , f i 1 


e, int, int, state - 


closefile: file, state 


-> state; 


rmode: - 


> i nt ; 




wmode: - 


> int: 




rwmode : 


-> int : 




openerr : 


-> int; 




openok : 


-> int; 




va 1 data : 


-> int; 




chardata 


; - > int; 




acti ve : 


memid, state -> 


boo 1 ; 


Properties 







tops tk ( s , i ni ts tk ( s ) ) is undefined; 

pops tk ( s , i ni ts tk ( s ) ) is undefined; 

pops tk ( s , i ni tarn () ) is undefined; 

stateaxiom(m, memaddr ) ; 

stateax i om ( r , regaddr) ; 

tops tk ( s ( pushs tk ( V , s , q ) ) = v; 

pops tk ( s ( pushs tk ( V , s , q ) ) = q; 

act i ve (m, i ni tarn () ) = falseC); 

act i ve ( 1 a 1 1 oc ( n, q ) q ) = true(); 

act i ce ( m , 1 f ree ( m , q ) ) = falseC); 

act i ve ( m, s torer ( V , r , q ) ) = active(m,q); 

act i ve ( m, s torem ( V , a , q ) ) = active(m,q); 

act i ve ( m, in i ts tk ( s , q ) ) = act i ve (m , q ) ; 

act i ve ( m, pushs tk ( V , s , q ) = act i ve ( ra, q ) ; 

acti ve ( m, pops tk ( s , q ) = active(m,q); 

act i ve ( m, out f i 1 e ( V , f , q ) = active(m,q); 

act i ve ( m, openf i 1 e ( s , f , X , y , q ) = active(m,q); 

act i ve (m, c 1 osef i 1 e ( f , q) = act i ve (m , q ) ; 

if active(m,q) = falseC) 

then 

f etchm (of f set (n, m) , q ) is undefined; 
end i f ; 

if active(m,q) = falseC); 
then 

s torem C V , of f set ( n , m ), q ) is undefined; 
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end i f ; 

if 1 t int ( n, ntoi ( n2) ) = true() 

then 

offset(n,offset(nl,startmemaddr( 

1 a 1 1 oc < n2, q ) ) ) ) = 
of f set ( sumint ( n, nl ) , 
startmemaddr<lal loc( n2, q ) ) ) } 

else 

offset(n,offset(nl, s tar tmemaddr ( 

1 a 1 1 oc ( n2, q) ) ) ) is undefined; 

end i f ; 

indi r (zeronat ( ) , m) = m; 

if whattype < f etchm ( ind i r (n, m ) , q ) = typememaddr ( ) 
then 

ind i r < succnat ( n ) , m ) = 

atomof memaddr (fetchm( indir(n,m) ,q) ) ; 

else 

i nd i r ( succnat ( n) , m) is undefined; 
end i f ; 

openf i 1 e ( s , f , n, openf i 1 e ( s , f , m, X , q ) ) is undefined; 
c 1 osef i 1 e ( f ( openf i 1 e ( s , f , n, X , q ) ) = q; 
inf i 1 e ( f , i ni tarn () ) is undefined; 
inf i 1 e ( f , c 1 ose ( f , q ) ) is undefined; 

inf i 1 e ( f , openf i 1 e < s , f , wmode <), X , q ) ) is undefined; 
outf i 1 e ( V , f , i ni tarn < ) ) is undefined; 
ou tf i I e < V , f , c 1 ose ( f , q ) ) is undefined; 

out f i 1 e < V , f , openf i 1 e ( s , f , rmode (), X , q ) ) is undefined 
outifle(v,f,openfile(s,f,m, char data ( ) , q ) ) 
is undefined; 



end amstate; 



Resource am is 

Extension of 

memaddress , 
intructiontype, 
typing, 
amstate 

Operands 

prog: memaddr , state -> state; 

cond : va 1 , memaddr , memaddr - memaddr; 
exq: i ns t r , memadd r , s tate -> state; 

Operators 

prog(m,q) = exq ( atomof i ns tr ( f etchm ( m , q )), m , q ) ; 
cond ( va 1 o f boo 1 ( true ( ) , ml , m2 ) ) = ml; 
cond ( va 1 of bo 1 1 ( f a 1 se < ) , ml , m2) ) = m2; 
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Properties 

exq( of f s t ( i , r ) , m , q ) = 

prog(nextmemaddr(m), 
storer ( 

va I of memaddr ( of f se t ( 

i . a tomof memaddr (fetchr(r,q)))), 

r, q) ) ; 

exq ( ] i nk ( r , n ) m, q ) = 

prog ( next memaddr ( m ) , 
storer ( 

valofmemaddr(startmemaddr( lal loc(n,q) ) ), 
r, storem(fetchr(r, q) , 

s tar t memaddr (lal loc(n,q),q)))); 
exq ( un 1 i nk ( r ) , m, q ) = 

prog(nextmemaddr(m) , 

1 free ( 

getmemid(atomofmemaddr(fetch(r,q) ) ), 
storer ( 

fetchm(atomofmemaddr(fetchr(r,q),q), 
r.q) ) ) ; 

exq (monads ( o , r 1 ), m, q ) = 
prog ( next memaddr ( m ) , 

storer(appl ymop (o, fetchr(rl,q) ), 
rl , q) ) ; 

exq(monad (o, rl , r2) , m, q) = 
prog ( next memaddr ( m ) , 

storer (appl ymop ( o,fetchr(rl,q)), 
r2, q) ) } 

exq (monad i ( o , V , r 1 ), m, q ) = 
prog(nextmemaddr(m) , 

storer(appl ymop ( o,v)),rl,q)); 
exq ( dyads ( o , r 1 , r2 ), m , q ) = 
prog(nextmemaddr(m), 
storer(applydop( 

o,fetchr(rl,q),fetchr(r2,q)),r2,q)); 
exq ( dyads i ( o , V , r 1 ) m, q ) = 
prog (next memaddr (m) , 

store(applydop(v, fetchr(rl,q) ) , rl,q) ) ; 
exq ( dyad ( o , r 1 , r2 , r3) , m , q ) = 
prog(nextmemaddr(m) , 

storer(applydop(o, 

fetchr(rl, q) , fetchr(r2, q) ) , r3, q) ) ; 
exq ( dyadi ( o , V , r 1 , r2 ) , m , q) = 
prog(nextmemaddr(m ) , 

storer(applydop(o, 

V, fetchr(rl,q) ) , r2,q ) ) ; 
exq ( tr iads ( o , r 1 , r2, r3 ) , m, q ) = 
prog(nextmemaddr(m) , 

storer(applytop(o, fetchr(rl, q) , 

fetch r(r2,q), fetchr(r3,q) ), r3,q) ) ; 
exq ( tr iads i ( o , V, rl , r2 ), m, q ) = 
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prog ( nex tmemaddr ( m ) , 

storer(applytop(o, v, 

f etchr (rl, q) , fetchr(r2, q) ) , r2,q) ) ; 
exq ( tr iad ( o , rl , r2, r3, r4 ) , m, q ) = 
prog ( nex tmemaddr (m ) , 

storer(applytop(o,fetchr(rl,q), 

fetchr(r2, q) , fetchr(r3, q) ) , r4,q) ) ; 
exq( triad! (o, V, rl , r2, r3) , m, q) = 
prog(nextmemaddr(m), 

storer(applytop(o, v, 

fetchr(rl, q) , fetchr(r2, q) ) , r3, q ) ) ; 
exqCquads (o, r 1 , r2, r3, r4) , m, q) = 
prog(nextmemaddr(m), 

s torer (app lyqop(o, fetchr(rl, q) , 
fetchr(r2,q), fetchr(r3,q), 
fetchr(r4, q) , r4, q) ) ; 
exq ( quad (o,rl,r2,r3,r4,r5),m,q) = 
prog (nex tmemaddr ( m ) , 

storer(applyqop(o, fetchr(rl, q) , 
fetchr(r2, q) , fetchr(r3, q) , 
fetchr(r4,q) , r5, q) ) ; 
exq(sexads(o, rl, r2, r3, r4, r5,r6),m,q) = 
prog(nextmemaddr(m) , 

storer(applyqop(o, fetchr(rl, q) , 
fetchr(r2, q) , fetchr(r3, q) , 
fetchr( r4, q) , fetchr(r5, q) , 
fetch(r6, q) , r6, q) ) ; 

exq(sexad(o, rl,r2, r3, r4, r5, r6, r7),m,q) = 
prog(nex tmemaddr (m ) , 

s to r er ( app lyqop(o, fetchrCrl, q) , 
fetchr(r2,q), fetchr(r3,q), 
fetchr(r4, q) , fetchr(r5,q) , 
fetch( r6, q) , r7, q) ) ; 

exq(octads(o,rl,r2,r3,r4,r5,r6,r7,r8),m,q) = 
prog(nextmemaddr(m) , 

storer(applyqop(o, fetchr(rl,q), 
fetchr(r2,q),fetchr(r3,q), 
fetchr(r4, q) , fetchr(r5, q) , 
fetch(r6,q), fetchr(r7,q), 
fetchr(r8,q) , r8, q) ) ; 

exq(octad(o,rl,r2,r3,r4,r5,r6,r7,r8,r9),m,q) = 
prog(nextmemaddr(m), 

s torer (app lyqop(o, fetchr(rl, q), 
fetchr(r2, q) , fetchr(r3,q) , 
fetchr(r4, q) , fetchr(r5, q) , 
fetch(r6,q),fetchr(r7,q), 
fetchr(r8,q), r9,q) ) ; 
e X q ( m o V i _m (v,ml),m,q) = 

prog(nextmemaddr(m) , 
storem(v,ml, q) ) ; 
exq ( mov i_pcr ( V , i ) , m, q ) = 

prog ( nex tmemaddr (m ) , 



104 



storem(v,offset(i,ra),q) ) ; 
exq(movi_r(v,r),m,q) = 

prog (nextmemaddr (m) , 
storem(v,r,q)); 
exq ( mov i_r i ( V , r ) , m , q) = 
prog ( nextmemaddr (m ) , 

storem(v,atomofmemaddr(fetchr(r,q) ,q) ) ; 
exq(movi_rid ( V, r, n) , m, q) = 
prog (nextmemaddr (m) , 
s to rem(v, offset ( 

n,atomofmeraaddr(fetchr(r,q) ,q) ) ; 
exq ( mov i_r i dn ( V , r , i 1 , i 2) , m, q ) = 

prog(nextmemaddr(m), 

storem(v,offset(i2, indir( 

11, atomofmemaddr(fetchr(r,q) , q) ) ; 

exq(mov_m_m(ml , m2) , m, q) = 
prog (nextmemaddr (m), 

storem(fetchm(ml,q), m2, q ) ) ; 
exq ( mov_m_r ( ml , r ) , m, q ) = 

prog(nextmemaddr(m), 

storem(fetchm(ml,q), r,q) ) ; 
exq(mov_m_r i (ml, r ) , m, q) = 
prog(nextmemaddr(m) , 

s torem ( f e tchm ( ml , q ) , 
atomofmemaddr(fetchr(r,q),q) ) ; 
exq (mov_m_r id (ml , r , n ) , m, q ) = 
prog(nextmemaddr(m) , 

storem(fetchm(ml,q),offset( 
n, atomof memaddr (fetchr(r,q),q)) ; 
exq ( mov_m_r idn(ml,r,il,i2),m,q) = 
prog (nextmemaddr (m) , 

storem(fetchm(ml,q),offset(i2, ind i r ( 
i 1 , atomof memaddr (fetchr(r,q),q) ) ; 

exq (mov_pcr_pcr ( i 1 , i2) , m, q) = 
prog ( nextmemaddr ( m ) , 

storem(fetchm(offset(il,m) ,q), 
offset(i2,m),q)); 
exq ( mov_pcr_r ( i 1 , r ) , m, q ) = 
prog (nextmemaddr (m) , 

storem(fetchm(offset( i 1, m) , q) , r, q) ) ; 
exq(mov__pcr_r i ( i 1 , r ) , m, q) = 
prog ( nextmemaddr ( m) , 

storem(fetchm(offset(il,m),q), 
atomof memaddr (fetchr(r,q),q)); 
exq ( mov_pcr_r i d ( i 1 , r , i 2 ) , m, q ) = 
prog (nextmemaddr (m), 

storem(fetchm(offset(il,m) , q) , offset( 

12 , atomof memaddr (fetch r(r,q) ,q) ) ; 
exq ( mov_pcr_r idn(il,r,n,i2),m,q) = 

prog(nextmemaddr(m) , 
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storem(fetchm(offset(il,m),q),offset(i2, 
ind i r ( n , atomof memaddr (fetch r(r,q),q)); 

exq ( mo v_r_m ( r 1 , ml ) , m, q ) = 
prog ( nex tmemaddr ( m ) , 

storem(fetchr(rl,q) ,ml, q ) ) ; 
exq(mov_r_pcr (rl,i),m,q) = 
prog ( nex tmemaddr ( m ) , 

storem(fetchr(rl,q),offset(i,m) ,q) ) ; 
exq ( mo v_r_r (rl,r2),m,q) = 
prog(nextmemaddr(m) , 

storem(fetchr(rl,q), r2,q) ) ; 
exq(mov_r_ri(rl,r2),m,q) = 
pro g ( nex tmemaddr ( m ) , 

storem(fetchr(rl, q) , 
atomof memaddr (fetchr(r2,q),q) ) ; 
exq(mov_r_rid(rl,r2,n),m,q) = 
prog ( nex tmemaddr ( m ) , 

storemCfetchr ( rl, q) , offsetC 
n, atomof memaddr(fetchr(r2,q) ,q) ) ; 
exq(mov_r_ridn(rl, r2, il, i2),m,q) = 
prog (nex tmemaddr (m) , 

storem(fetchr(rl, q) , offset(i2, indir( 
i 1 , atomof memaddr (fetchr(r2,q),q)) ; 

exq(mov_ri _m (rl,ml),m,q) = 
prog(nextmemaddr(m) , 

storem( fe tchm ( atomof memaddr (fetchr(rl,q),q), 
ml , q ) ) ; 

exq(mov_r i__pcr (rl,i),m,q) = 
pr og ( nex tmemadd r ( m ) , 

storem( f e tchm ( atomo f memaddr (fetchr(rl, q) , q) , 
offset(i,m),q)); 
exq(mov_ri_r(rl,r2),m,q) = 
prog(nextmemaddr(m) , 

storer ( f e tchm ( atomof memaddr (fetchr(rl,q),q), 
r2, q) ) ; 

exq(mov_ri_ri (rl, r2) ,m,q) = 
pr o g ( nex tmemaddr ( m ) , 

storem(fetchm ( atomof memaddr (fetchr(rl,q),q), 
atomofmemaddr(fetchr(r2, q) ) , q) ) ; 
ex q ( mo v_r i _r id(rl,r2,n),m,q) = 
pr og ( nex tmemaddr ( m ) , 

storem(fetchm (atomo f me maddr(fetchr(rl,q),q), 
offset(n,atomofmemaddr(fetchr(r2,q) ) , q) ) ; 
exq(mov_ri_ridn(rl,r2, il, i2),m,q) = 

prog(nextmemaddr(m) , 

storem(fetchm( atomof memaddr ( f etchr ( r 1 , q ) , q ) , 
offset(i2, indir( 

i 1 , atomof memaddr (fetchr(r2,q) ) ),q) ) ; 
exq ( mo v_r i d_m (rl,il,ml),m,q) = 
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prog ( nex tmemaddr ( m ) , 

storem(fetchm(offset(il, 

atomof memaddr (fetchr(rl,q) ) ) ,q) ,ml,q) ) ; 
exq(mov_rid_pcr ( rl , i 1 , i2) , m, q) = 
prog(nextmemaddr(m) , 

storem ( f etchm (offset(il, 
atomof memaddr (fetchr(rl,q))),q), 
of f set( i2, m) , q) ) ; 

Gxq ( mov_r i d_r ( r 1 , n, r2 ) , m, q ) = 

prog (nex tmemaddr <m) , 

storer(fetchm(offset(n, 

atomofmemaddr(fetchr(rl,q) ) ) ,q) , r2,q) ) ; 
exq(mov_r id_r i ( rl , i , r2) , m, q) = 
prog ( nex tmemaddr ( m ) , 

storem (fetchm(offset( i, 
atomof memaddr (fetchr(rl,q) ) ) ,q) , 
atomof memaddr (fetchr(r2,q) ) , q) ) ; 
exq ( mov_r i d_r id (rl,il,r2,il),m,q) = 
prog ( nex tmemaddr ( m ) , 

storem(fetchm(offset( il, 
atomof memaddr (fetchr( rl,q) ) ) , q) , 
offset( il, atomof memaddr (fetch r(r2,q) ) ,q) ) ; 
exq(mov_rid_ridn(rl, r2, il, i2, i3) ,m,q) = 
prog (nex tmemaddr(m) , 

storem (fete hm(offset( il, 
atomofmemaddr(fetchr(rl,q) ) ) ,q) , 
offset( i3, ind i r ( 

i2 , atomof memaddr (fetchr(r2,q)))),q)); 

exq ( mov_r i dn_m (rl,n,il,ml),m,q) = 
prog (next memad dr (m) , 

storem(fetchm(offset( il, 
indi r (n, atomof memaddr ( 
fetchr(rl,q)))),q),ml,q)); 
exq(mov_r idn_pcr (rl,n,il,i2),m,q) = 
prog(nextmemaddr(m) , 

storem(fetchm(offset( il, 

ind i r ( n, atomof memaddr (fetchr(rl,q) ) ) ),q), 
offset( i2,m) ,q) ) ; 

exq ( mov_r idn_r (rl,il,i2,r2),m,q) = 
prog(nextmemaddr(m) , 

storer(fetchm(offset( i2, 
indir(il, atomof me maddr( 
fetchr(rl,q) ) ) ), q) , r2,q) ) ; 
exq(mov_r i dn_r i (rl,il,i2,r2),m,q) = 
prog ( nex tmemaddr ( m ) , 

storem(fetchm(offset(i2, 

indir(il, atomof memaddr (fetchr(rl,q)))),q), 
atomof memaddr (fetchr(r2,q) ) ,q) ) ; 
exq ( mov_r i dn_r id(rl,il,i2,r2,i3),m,q) = 
prog ( nex tmemaddr ( m ) , 

storem(fetchm(offset( i2. 
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indir(il,atomofmemaddr(fetchr(rl,q) ) ) ) ,q), 
offset(13, atomof memaddr (fetchr(r2, q) ) ,q) ) ; 
exq(mov_ri dn_r idn(rl,r2, il,i2,i3,i4),ra,q) = 
prog (next memaddr (m) , 

storem(fetchm(offset(i2, 

i nd i r ( i 1 , atomof memaddr (fetchr(rl,q) )) ),q), 
offset(i4, indir( 

i 3, atomof memaddr (fetchr(r2,q) ) )),q) ) ; 
exq(push_i ( V, s ) , m, q) = 

pr og ( nex t memaddr ( m ) , 
pushs tk ( V , s , q ) ) ; 
exq ( push_ra (ml , s ) , m , q ) = 
prog (next memaddr (m) , 

pushstk(fetchm(ml,q), s,q) ) ; 
ex q ( push_pcr ( i , s ) , m, q ) = 
prog ( nex t memaddr (m ) , 

pushstk(fetchm(offset(i,m) ,q) , s,q) ) ; 
exq ( push_r ( r , s ) , m, q ) = 

prog (next memaddr (m) , 

pushstk(fetchr(r,q), s,q) ) ; 
exq ( pus h_r i ( r , s ) , m, q ) = 
prog ( nex tmemaddr ( m) , 

pushs tk ( atomof memaddr (fetchr(r,q) ) ,s,q) ) ; 
exq ( push_r i d ( r , n, s ) , m, q ) = 
prog ( nex tmemaddr ( m ) , 

pushstk(fetchm(offset(n, 
atomof memaddr (fetch r(r,q))),q),s,q)) ; 
exq ( push_r i dn ( r , i 1 , i 2, s ) , m, q ) = 
prog (nex tmemaddr (m) , 

pushstk(fetchm(offset(i2,indir(il, 
atomof memaddr (fetchr(r,q)))),q),s,q)); 
exq ( pop_x ( s ) , m, q ) = 

prog ( nex tmemaddr ( m ) , 
popstk ( s , q ) ) ; 
exq ( pop_m ( s , ml ) , m, q ) = 
prog ( nex tmemaddr (m ) , 

popstk(s,storem(topstk(s,q),ml,q) ) ) ; 
exq ( pop_pcr ( s , i ) , m, q ) = 
prog ( nex tmemaddr ( m) , 

popstk(s,storem(topstk(s,q), 
offset(i,m),q))); 
exq ( pop_r ( s , r ) , m, q ) = 

prog (nex tmemaddr (m) , 

popstk(s,storer(topstk(s,q),r,q) ) ) ),m,q) ; 
exq ( pop_r i ( s , r ) , m, q ) = 
prog ( nex tmemaddr ( m ) , 

popstk(s, storem(topstk(s, q), 
atomof memaddr (fetchr(r,q) ) ,q) ) ) ; 
exq ( pop_r id ( s , r , n ) , m, q ) = 
prog ( nex tmemaddr ( m ) , 

popstk(s,storem(topstk(s,q),offset(n, 
atomof memaddr (fetchr(r,q))),q))); 
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exq ( pop_r i dn ( s , r , i 1 , i2 ) , m, q ) = 

prog(nextmemaddr(m) , 

popstk(s,storem<topstk(s,q),offset(i2, 
ind i r ( i 1 , atomof memaddr (fetchrCr, q) ) ) ) , q) ) ) ; 
exqCnop, m, q) = 

prog(nextmemaddr(m),q) ; 
exq( stop, m, q) = 

prog(m,q) = q; 
exq ( jmp ( ml ) , m, q ) = 

prog (ml , q) ; 
exq( jmp_i (ml ) , m, q) = 

prog(atomofmemaddr(fetchm(ml, q) ) , q) ; 
exq ( jmp_r ( r ) , m, q) = 

prog (atomof memaddr (fetchr(r,q)),q) ; 
exq ( bra ( n) , m, q ) = 

prog(offset(n, nex t memaddr ( m ) ) , q ) ; 
exq ( bra_r ( r ) , m, q ) = 

prog(offset(atomofint(fetchr(r, q) ) , 
nextmemaddr(m) ) , q) ; 
exq ( i f ( o, r 1 , r2, ml ) , m , q ) = 

prog(cond(applyrop(o, fetchr (rl, q) , fetchr(r2, q) ) , 
ml,nextmemaddr(m)),q) ; 
exq ( i f i ( o , r , V, ml ) , m, q) = 

prog(cond(applyrop(o, fetchr (r, q) , v, 
ml,nextmemaddr(m) ),q ) ; 
exq( i f te ( o , r 1 , r2, ml , m2 ) , m, q ) = 

prog(cond(applyrop(o, fetchr(rl,q) , fetchr(r2, q), 
ml , m2) , q) ; 

exq ( i f te i ( o , r , V , ml , m2) , m, q) = 

prog(cond(applyrop(o, fetchr(r,q) , v,ml, m2 ) , q ) ; 

exq ( i f _pcr ( o , r 1 , r2, n ) , m, q ) = 

prog(cond(applyrop(o, fetchr(rl, q) , fetchr(r2, q) , 
offset(n,nextmemaddr(m) ), next memaddr (m) ) , q) ; 
exq ( i f i_pcr ( o, r , V, n ) , m, q) = 

prog(cond(applyrop(o,fetchr(r,q),v), 
offset(n, next memaddr (m) ) , nextmemaddr(m) ) , q) ; 
exq ( i f te ( o, r 1 , r2, i 1 , i2 ) , m, q) = 

prog(cond(applyrop(o, fetch r(rl, q) , fetchr(r2, q) , 
offset(il,nextmemaddr(m) ), 
offset( i2, nex tmemaddr (m ) ) ) , q ) ; 
exq ( i f te i ( o, r , V, ml , m2) , m, q ) = 

prog(cond(applyrop(o, fetchr(r, q) , v) , 
offset(il,nextmemaddr(m) ), 
offset( i2,nextmemaddr(m) ) ) , q) ; 
exq( test(o, rl , ml ) , m, q) = 

prog(cond(applybop(o, fetchr(rl,q) ) , 
ml,nextmemaddr(m)),q ) ; 
exq ( tes tm ( o, m2, ml ) , m , q ) = 

prog(cond(applybop(o, fetchm(m2, q) ) , 
ml , nex tmemaddr (m) ) , q) ; 
exq ( tes te ( o, r 1 , ml , m2 ) , m, q) = 
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prog(cond(applybop(o, fetch r(rl,q) ) , 
ml , m2 ) , q > ; 

exq ( tes tme ( o , m3 , ml , m2 ) , m, q ) = 

prog ( cond ( app 1 ybop ( o , f e tchm ( m3 , q ) ) , 
ml , m2) , q) ; 

exq( test_pcr (o,rl,n),m,q) = 

prog(cond(applybop(o, fetchr(rl,q) ) ; 
offset(n,nextmemaddr(m) ) , 
nextmemaddr(m) ) , q) ; 
exq ( tes tm_pcr (o,m2,n),m,q) = 

prog ( cond (applybopCo, fetchmC m2, q ) ) ; 
offset (n, nextmemaddr (m) ) , 
nextmemaddr(m) ), q) ; 
exq ( tes temper (o,rl,il,i2),m,q) = 

prog(cond(appl ybop (o, fetchr(rl,q) ) ; 
offsetC il, nextmemaddr ( m ) ) , 
offset(i2,nextmemaddr(m)) ),q) ; 
exq ( tes tme_pcr ( o , m3, il,i2),m,q) = 

prog(cond(applybop(o, fetchm(m3,q) ) ; 
offsetC il, nextmemaddr (m) ) , 
offsetC i2, nextmemaddrCm) ) ) , q) 
exqCjsrCml,s),m,q) = 
progCml, pushstkC 

valofmemaddrCnextmemaddrCm) ) , s,q) ) ; 
exqCjsr_iCml,s),m,q) = 

pr og C a tomof memaddr Cfetchm’Cml, q) ) , 
pushstkCvalofmemaddrC nextmemaddr C m ) ) , s , q ) ) ; 
exqCjsr_iCrl,s),m,q) = 

progCatomofmemaddrCfetchrCrl,q) ), 
pushstkC valofmemaddrCnextmemaddrCm) ) , s,q) ) ; 
exqCbsrCn,s),m,q) = 

progCoffsetCn, nextmemaddrCm) ) , 
pushstkCvalofmemaddrCnextmemaddrCm) ), s,q) ) ; 
exqCbsr_rCr,s),m,q) = 

progCoffsetCatomofintCfetchrCr, q) ) , 
nextmemaddrCm) ) , 

pushstkCvalofmemaddrCnextmemaddrCm) ), s,q) ) ; 
exqCrtsCs),m,q) = 

pr og C at omof memaddr CtopstkCs,q) ) ,popstkCs,q) ) ; 
exqCopenCs),m,q) = 

progCnextmemaddr Cm) ,openfi leC 

atomofstr.charCtopstkCs,popstkCs,popstkCs, 
pops tk C s , q ) ) ) ) ) , 

atomoffi leCtopstkCs, popstkCs,popstkCs,q) ) ) ), 
atomofintCtopstkCs,popsstkCs, q) ) ) , 
atomofintCtopstkCs, q) , 
pops tk C s , q ) ) ) ; 
exqCcloseCs),m,q) = 

prog C nex tmemaddr Cm),closefi leC 
atomoffi leCtopstkCs, q)), 
pops tk C s , q ) ) ) ; 
exqCreadCs),m,q) = 
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prog ( nex tmemaddr (m),storem(infi le( 

atomoffi Ie(topstk(s,popstk(s,q ) ) ) , 
popstk ( s , q ) ) , 

atomof memaddr ( topstkCs, popstk(s, q) ) , 
popstk ( s , q) ) ) ; 
exq ( wr i te ( s ) , m, q ) = 

prog ( nex tmemaddr (m),outfile(fetchm( 

atomofmemaddr( topstkCs, popstkCs, q) ) ) , 
pops tk ( s , q ) ) ; 
atomoffi le(topstk(s,q) ), 
popstk ( s , q ) ) ) ; 



end am; 
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APPENDIX B; COMPLETE SPECIFICATION OF A SUBSET OF 



THE ABSTRACT PROCESSOR 



Resource intructions is 

Extension of 
natura 1 , 
integer , 
memaddress , 
r egaddr ess , 
s tkaddr ess , 
operatorc lasses, 
intructiontype, 
typing 

Operands 

Operators 

monad: mop, regaddr , regaddr -> instr; 

dyad: dop, regaddr , r egaddr , regaddr -> instr; 

triad: top, regaddr, regaddr, regaddr, regaddr -> instr 

mov_m_r : memaddr , regaddr -> instr; 

mov_r_m: regaddr , memaddr -> instr; 

mov_r_r: regaddr , regaddr -> instr; 

push_r: regaddr , s tkaddr -> instr; 

pop_r: s tkadd r , r egadd r -> instr; 

• regaddr -> instr; 

if: re 1 op, regaddr , regaddr , memaddr -> instr; 

jsr: memaddr , s tkaddr -> instr; 
rts: stkaddr -> instr; 

Proper t i es 
end intructions; 



Resource amstate is 

Extension of 
boo 1 ean , 
natura 1 , 
integer, 
str(character) , 
memaddress , 
regaddr ess , 
f i 1 es , 

i dent i f i er s , 
typing 
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static 

Operands 

state; 

Operators 

fetchm: memaddr , state -> va 1 ; 
fetchr: regaddr, state -> val; 

storera: va 1 , memaddr , state -> state; 
storer: va I , regaddr , state -> state; 
topstk: stkaddr , state -> val; 
pushstk: va 1 , s tkaddr , s tate -> state; 
popstk: stkaddr , state -> state; 
initam: -> state; 

initstk; stkaddr , state -> state; 
active: memid, state -> bool; 

Properties 

topstk ( s , ini tstk ( s ) ) is undefined; 
popstk ( s, ini tstk ( s ) ) is undefined; 
pops tk ( s , i ni tarn () ) is undefined; 
s tateax i om ( m, memaddr ) ; 
stateaxiom(r, regaddr) ; 

tops tk ( s ( pushstk ( V, s , q ) ) = v; 

popstk ( s ( pushstk ( V , s , q ) ) = q; 
active (m, ini tam( ) ) = false(); 
act i ve ( m , storer ( V , r , q ) ) = active(m,q); 
act i ve ( m, s torem ( V , a , q ) ) = active(m,q); 
act i ve ( m, i ni tstk ( s , q ) ) = active(m,q); 
act i ve (m, pushstk ( V , s , q ) = active(m,q); 
active (m, popstk ( s, q) = active(m,q); 
if active(m,q) = false() 
then 

f e tchm ( of f se t ( n , m ) , q ) is undefined; 
end i f ; 

if active(m,q) = false(); 
then 

storem( V, of f set (n, m) , q) is undefined; 
end i f ; 

if 1 t int ( n, nto i ( n2 ) ) = true() 

then 

offset(n,offset(nl, s tar tmemaddr ( 

1 a 1 1 oc ( n2, q ) ) ) ) = 
offset(sumint(n,nl) , 
startmemaddrC lal loc(n2,q) ) ) ; 

else 

offset (n, offset (nl, star tmemaddr ( 

1 a 1 1 oc ( n2, q ) ) ) ) is undefined; 

end i f ; 

i nd i r ( zerona t ( ) , m ) = m; 

if whattype ( fetchm ( i nd i r ( n, m ), q ) = typememaddr ( ) 
then 
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indir(succnat(n),m) = 

atomofmemaddr(fetchm(indir(n,m),q) ) 

else 

i nd i r ( succnat ( n ) , ra ) is undefined; 
end i f ; 

Dynamic 

Entry Places 

r eq_f e tchra ( ne 1 1 abe 1 ) C memaddr . state ] ; 
req_storem (netlabel ) Cval •memaddr. state] ; 

req_f etchr (netlabel ) Cregaddr. state] ; 
req_stor er (netlabel ) Cval . regaddr. state] ; 

r eq_topstk (netlabel ) Cstkaddr.state] ; 
req_pushstk (netabel ) Cval , s tkaddr . state ] ; 
r eq_pops t k ( ne 1 1 abe 1 ) C s tkaddr . state] ; 
req_in i tstk(netlabel ) Cstkaddr, state] ; 

req_ini tarn ( ) C ] 

Exit Places 

avai 1 etc hm (netlabel ) Cval ] ; 
avai l__storem(netlabel ) [state] ; 

avai l_fetchr (netlabel ) Cval ] ; 
avai l_storer(netlabel ) [state] ; 

avai l_topstk(netlabel ) Cval ] ; 
avail _pushs tk (netlabel ) [state] ; 
avail _pops tk (netlabel ) [state] ; 
avai l_initstk(netlabel ) [state] ; 

avai l_i nit am [state] ; 

Internal Places 

access_avai 1C]; 
f etchm_f or (netlabel)C]; 
f etchm_act i va ted [ memaddr • state] ; 
f etchm_comp letedCval ] ; 
storem_for( netlabel ) [ ] ; 
s tor em__act i va ted Cval .memaddr. state] ; 
storem_completedCstate] ; 

access_avai 1C]; 
fetchr__for(netlabel ) C ] ; 
f etchr_act i vatedCregaddr. state] ; 
fetchr_completedCval ] ; 
storer_for(netlabel ) C ] ; 
s torer_act i vatedCval . regaddr. state] ; 
stor er_comp letedCstate] ; 
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accessk_avai 1 C ] ; 

tops tk_f or ( net 1 abe 1 ) C 3 ; 

tops tk_act ivatedCstkaddr. state] ; 

tops tk_comp 1 etedCval 3 ; 

pushstk_for( net 1 abe 1 ) [ 3 ; 

pushs tk_act i vated Cval . stkaddr. state] ; 

pushs tk_comp letedCstate] ; 

popstk_for( net 1 abe 1 ) C 3 ; 

pops tk_act i vatedCstkaddr. state] j 

popstk_comp 1 etedC state ] ; 

initstk_for(netl abe 1 ) C 3 ; 

ini tstk_acti vated Cstkaddr. state] ; 

ini tstk_comp 1 eted C state] ; 



Initial State 

=> accessm_avai 1 t 3 ; 

=> accessr_avai 1 C 3 ; 

=> accessk_avai 1 C 3 ; 

Trans i t ions 

act_fetchm: Cmemaddr . state] , C 3 -> Cmemaddr . state 3 , C 3 

per f orm_f etchm : C memaddr . s tate 3 -> Cval 3; 

f inish_f etchm : Cval3,C3 -> [val3,C3; 

act_storem: [ va 1 . memaddr . s tate 3 ,[ 3 -> 

[val .memaddr. state] , C 3 ; 

per f orm_s tor em : [ va 1 . memaddr . s tate 3 -> Estate]; 

f i ni sh_storem ; Estate], C3 -> Estate], E3; 

act_fetchr; E r egaddr . s tate 3 , E 3 -> 

Eregaddr. state] , E 3 ; 

per f orm_f etchr : E regaddr . s tate 3 -> Eval3; 

f inish_f etchr : Eval3,E3 -> Eval3,E3; 

act_storer: E va 1 . regaddr . s tate 3 , E 3 -> 

Eval . regaddr. state] , E 3 ; 

perf orm_storer : E va 1 . regaddr . s tate 3 -> Estate]; 

f inish_storer ; Estate], E3 -> Estate], E3; 

act_topstk: E s tkaddr . s tate 3 , E 3 -> 

E stkaddr . state] , E 3 ; 

per f orm_topstk : E s tkaddr . s tate 3 -> Eval 3; 

f i ni sh_topstk : Eval3,E3 -> Eval3,E3; 

act_pushs tk : E va 1 . stkaddr . s tate 3 , E 3 -> 

Eval. stkaddr. state], E3; 

per f orm_pushstk ; E va 1 . s tkaddr . s tate 3 -> Estate]; 
f i ni sh_pushs tk : Estate], E3 -> Estate], E3; 

act__popstk; E s tkaddr . s tate 3 , E 3 -> 

Estkaddr. state] , E 3 ; 

per f orm_popstk : E stkaddr . state] -> Estate]; 

f i n i sh_pops tk ; Estate], E3 -> Estate], E3; 
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act_initstk: [ stkaddr . state ], C ] -> 

Cstkaddr. state], []; 

perf orm_ini tstk : C stkaddr . state ] ~> [state]; 

f ini sh_ini ts tk : [state], [] -> [state], []; 

per f orm_i n i tarn : [] -> [state]; 

Properties 

act_f etchm ( req_f etchm ( 1 ) [ra. q] , accessm_avai 1 [ ] ) => 
f etchm^f or ( 1 ) [ ] , f etchm_ac t i vated [ m. q] ; 
per f orm_f etchm ( f e tchm^act i vated [m. q] ) => 
f etchra^comp 1 e ted [ v ] ; 

f i ni sh_f e tchm ( f e tch_comp 1 eted [ v ] , f etchm_f or (!)[]) 

= > avail etc hm(l)[v], accessm_avai 1 [ ] ; 
act_s tor em (req_storem(l)[v.m.q], accessm_avail[]) => 
storem_for(l)[], s torem_act i vated [ v. m. q] ; 
perform_storem(storem_activated[v.m.q]) => 
s torem_comp 1 eted [ q ] ; 
f i ni sh_s tor em (storem_compIeted[q] , 
s torem_f or (!)[]) => 

avail _storem(l)[q], accessm_avail[]; 

act_f etchr ( req_f etchr (l)[.q], accessr_avail[]) => 
fetchr_for( 1 ) [], f etchr_act i vated [ . q] ; 
per for m_f etch r ( f etch r_acti vated [ . q] ) => 

fetchr_completed[v] ; 

f i n i sh_f e tchr ( f e tch_comp leted[v], fetchr_for( 1 ) [ ]) 

=> avail_fetchr(l)[v], accessr_avai 1 [ ] ; 
act_storer(req_storer( 1 ) [v. .q], access r_ava i 1 [ ] ) 

=> storer_for(l)[], s tor er_act i vated[v. . q] ; 
per for m_s tore r (storer_activated[v..q]) => 
storer_completed[q] ; 
f i ni sh_s tor er ( s tor er_comp 1 e ted [ q ] , 

storer_for(l)[]) => avail _storer(l)[q], 
accessr_avai 1 [ ] ; 

act_tops tk ( req_topstk ( 1 ) [ s . q ] , accessk_avai I [ ] ) => 

topstk_for( 1 ) [ ], tops tk_act ivated[s.q]; 
perf orm_tops tk ( tops tk_act i vated[s.q]) => 
topstk_completed[v] ; 

f ini sh_topstk (topstk_compIeted[v],topstk_for(l)[] => 
avail _tops tk ( 1 ) [ v ] ; 

ac t_pushs tk ( req_pushs tk ( 1 ) [ v . s . q ] , acces s k_avai 1 [ ] ) 

= > pushstk_for(l)[], pushs tk_ac t i vated[v.s.q]; 
per form _pushs tk ( pus hs t k_ac t i vated[s.q]) => 
pushs tk__comp leted[ql] ; 

finis h_pushs tk (pushstk_completed[ql ], pushstk_for( I ) [ ] 
=> avail _pushs tk ( 1 ) [ ql ] ; 

act_popstk ( req_popstk ( I ) [ s . q] , accessk_avai 1 [ ] ) => 

popstk_for( 1 ) [ ], pops tk_act i vated [ s. q] ; 
per f orm_popstk ( popstk_act i vated[s.q]) => 
pops tk_comp leted[ql]; 
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f ini sh_pops tk ( pops tk_comp letedCql], pops tk_f or ( 1 ) [ ] => 
avail _popstk ( 1 ) [ ql 3 ; 

act_ini ts tk ( req_ini ts tk ( 1 ) [ s . q ] , accessk_avai 1 C ] ) => 
initstk_for( 1 ) I 3 , initstk_activated[s. q3 ; 

perf orm_i ni ts tk ( ini ts t k_act ivat©dCs.q3) => 
ini tstk_comp letedCql3; 

f ini sh_in i ts tk (ini ts tk_comp letedCql3, ini ts tk_f or ( 1 ) C 3 
= > avai 1 _i ni ts tk ( 1 ) C ql 3 ; 

perf orm_i n i tarn ( req_in i tarn [ 3 ) => ava i 1 _ini tarn C s tate 3 ; 

end amstate; 



Resource am is 

Extension of 

memaddress , 
intructiontype, 
typing, 
amstate 

Operands 

prog: memaddr , s tate -> state; 

cond: va 1 , memaddr , memaddr - memaddr; 
exq: instr, memaddr , state -> state; 

Operators 

prog(m,q) = e xq ( atomof i ns t r ( f e tchm ( m , q ) ) , m , q ) ; 
cond ( va 1 of boo 1 ( true ( ) , m, m2) ) = m; 
condCvalofbol 1 (false( ) ,m, m2) ) = m2; 

Properties 

exq(monad (o, r , r2) , m, q) = 
prog(nextmemaddr(m) , 

storer(applymop(o, fetchr(r, q) >, 
r2,q)); 

exq ( dyad ( o, r , r2, r3) , m, q ) = 
progCnextmemaddr (m) , 

storer(applydop(o, 

fetchr(r,q), fetchr(r2, q) ), r3,q) ) ; 
exq(triad(o,r,r2,r3,r4),m,q) = 
prog(nextmemaddr(m) , 

storer(applytop(o, fetchrCr, q) , 

fetchr ( r2, q) , fetchr ( r3, q) ) , r4, q) ) ; 
exq (mov_m_r ( m , r ) , m , q ) = 
prog(nextmemaddr(m) , 

storem(fetchm(m,q),r,q)) ; 
exq ( mov_r_m ( r , m ) , m , q ) = 
progCnextmemaddrCm), 

storem(fetchr(r,q),m,q) ) ; 
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exqCmov_r_r(r,r2),m,q) = 
prog ( nex tmemaddr Cm) , 

storem(fetchr(r,q) , r2,q) ) ; 
exq ( push_r ( r , s ) , m, q ) = 
prog(nextmemaddrCm) , 

pushstk(fetchrCr,q),s,q)) ; 
exq ( pop_r C s , r ) , m, q ) = 

prog ( nex tmemaddr (m) , 

popstk(s,storerCtopstk(s,q) , r,q) ) ) ) ,m,q) ; 
exq ( jmp_r C r ) , m, q ) = 

prog ( a tomof memaddr Cfetchr(r,q)),q); 
exq(if(o,r,r2,mi),m,q) = 

progCcondCapplyropCo, fetchr(r,q) , fetch r(r2, q) ) , 
mi,nextmemaddr(m) ),q) ; 
exq(jsr(m,s),m,q) = 
prog Cm, pushstkC 

valofmemaddrC nex tmemaddr ( m ) ) , s , q ) ) ; 
exqC rts ( s ) , m, q) = 

prog ( atomof memaddr (topstk(s,q) ),popstk(s,q) ) ; 



Dynamic 

Entry Places 

req__pr og C memaddr . state] ; 

r eq_exq C netlabel ) Cinstr. memaddr . state ] ; 
req_cond (netlabel ) Cval .memaddr. memaddr ] ; 
Exit Places 

avail _ex q (netlabel ) C memaddr . state] ; 

avail _cond (netlabel ) [ memaddr ] ; 

Internal Places 

prog_ava i 1C]; 

prog etch C memaddr . state] ; 
prog _instrC memaddr. state] ; 
prog_per f ormC ] 

exq_ava i 1 C ] ; 

exq_f or (netlabel ) C ] ; 

exq_monad_act ivatedCstate] ; 
exq_monad_f etchC state ] ; 
exq_monad_app 1 y [ s ta te ] ; 
exq_monad_s tor e C ] ; 

exq_dyad_act i vated [ s ta te ] ; 
exq_dyad_f etch C state ] ; 
exq_dyad_app 1 y [ state ] ; 
exq_dyad_s tore C ] ; 
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exq_tr iad_act i vated C s tate ] ; 
exq_triad_f etchCstate] ; 
exq_tr iad_app I y [ s tate ] ; 
exq_tr i ad_s tore C ] ; 

exq_mov_r_r_act i vated [ state ] ; 
exq_mov_r_r_perform[ state ] ; 
exq_mov_r_r_s tore [ ] ; 

exq_mov_r_ra_acti vated [ state] ; 
exq_mov_r_m_perf orm[ state] ; 
exq_mov_r_m_s tore [ ] ; 

exq_mov_m_r_act i vated [ state ] ; 
exq_mov_m_r_per form [ s tate ] ; 
exq_mov_m_r_s tore [ ] ; 

exq_push_r_act i vated C state ] ; 
exq_push_r_per f orm[ state] ; 
exq_push_r_push [ ] ; 

exq_pop_r_acti vated [ s tate ] ; 
exq_pop_r_perf ormCstate] ; 
exq_pop_r_s tore [ ] ; 
exq_pop_r_pop[ ] ; 

exq_jmp_r_act i vatedCstate] ; 
exq_jmp_r_perf ormC state ] ; 
exq_jmp_r_conver ting [ s tate ] ; 

exq_i f_acti vated [ state] ; 
exq_i f_f etch [ s tate ] ; 
exq_i f _cond [state ] ; 

cond_acti vated Cmemaddr . memaddr ] ; 

Initial State 

=> prog_avai 1C]; 

= > exq_avai 1C]; 

= > cond_avai 1 [ ] ; 

Transitions 

act i vate_prog : C ], C memaddr . state ] -> 

[memaddr. state], C memaddr . state] ; 
get_instr_prog : [memaddr . s tate ], C va 1 ] -> 

[memaddr . s tate ] , C va 1 ] ; 
perf orm_prog : Cmemaddr . state ], C instr ] -> 

[], Cinstr. memaddr . state] ; 
finish_prog: C ], C memaddr . state ] -> 

[ ] , [ memaddr . state] ; 
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act i va te_exq_monad : C i ns t r . memaddr .state], [] -> 

[state], [instr], [instr], [instr], [memaddr]; 
s tar t_exq_monad : [state], [regaddr], -> 

[state], [regaddr. state] ; 

3^PP 1 y_exq_monad : [state], [operator], [val] -> 

[state], [operator. val ] ; 
s tor e_exq_monad : [state], [val], [ operator ] -> 

[ ], [val . regaddr. state] ; 
f i ni sh_exq__monad : [], [state], [memaddr] -> 

[memaddr. state] ; 

act i vate_exq_dyad : [instr. memaddr. state],[] -> 

[state], [instr], [instr], [instr], [instr], [memaddr ] ; 
s tar t_exq_dyad : [state], [regaddr], [ regaddr ] -> 

[state], [regaddr. state], [regaddr. state]; 
s^pp 1 y_exq_dyad : [state], [operator], [val], [val] -> 

[state], [operator. val ,val ] ; 
s tore_exq_dyad : [state], [val ], [regaddr] -> 

[ ], [val . regaddr. state] ; 
f inish_exq_dyad : [], [state], [memaddr] -> 

[memaddr. state] ; 

act i vate_exq_t r iad: [instr. memaddr . state], [] -> 

[state], [instr], [instr], [instr], [instr], 

[instr], [ memaddr ] ; 

star t_exq_tr iad: [state], [regaddr], [regaddr], [regaddr] -> 

[state], [regaddr. state], [regaddr], [regaddr]; 
app 1 y_exq_tr iad: [state], [operator], [val ], [val ], [val ] -> 

[state], [ operator .val. val. val]; 
s tor e_exq_tr iad: [state], [val], [ regaddr ] -> 

[], [val. regaddr. state]; 
f ini sh_exq_tr iad: [], [state], [memaddr] -> 

[memaddr. state] ; 

act i va t e_exq_mo v_r _r : [instr. memaddr. state], [] -> 

[state], [instr], [instr], [ memaddr ] ; 
s tar t_exq_mov_r_r : [start], [regaddr] -> 

[state], [regaddr. state]; 
s tor e_exq__mov_r_r : [state], [regaddr], [val ] -> 

[ ], [val . regaddr. state] ; 
finis h_exq_mo v_r_r : [], [state], [memaddr] -> 

[memaddr. state] ; 

act i va te_exq__mo v_r _m : [instr. memaddr. state], [] -> 

[state], [instr], [instr], [memaddr]; 
star t_exq_mov_r_m : [start], [regaddr] -> 

[state], [regaddr. state]; 
s tore_exq_mov_r_m : [state], [memaddr], [ va 1 ] -> 

[ ], [val .memaddr. state] ; 
finis h_exq__mov_r_m : [], [state], [memaddr] -> 

[memaddr. state] ; 
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act i vatG_exq_mov_tn_r : C instr . memaddr . state ],[ ] -> 

[state], Cinstr], [instr], [memaddr]; 
start_exq_mov_m_r : [ s tar t ],[ memaddr ] -> 

[state] , [regaddr. state] ; 
s tore_exq_mov_m_r ; [ state ],[ regaddr ],[ va 1 ] -> 

[], [val. regad dr. state]; 
f i n i sh_exq_mo v_m_r : [],[ state] , [memaddr ] -> 

[ memaddr . state ] ; 

activate_exq_push_r : [ instr . memaddr . state ],[ ] -> 

[state], [instr], [inestr], [memaddr]; 
f etch_exq_push_r : [ s tate ],[ regaddr ] -> 

[state], [regaddr. state]; 
push_exq_push_r : [ s tate ] , [ va 1 ] , [ s tkaddr ] -> 

[ ] , [stkaddr. state] ; 

f inish_exq_push_r : [],[ s tate ],[ memaddr ] -> 

[memaddr. state] ; 

acti vate_exq_pop_r : [ i ns tr . memaddr . s tate ],[ ] -> 

[state], [instr], [instr], [ memaddr ] ; 
pop_exq_pop_r : [ state ],[ stkaddr ] -> 

[state], [stkaddr. state] ; 
store_exq_pop_r : [ state ],[ va 1 ],[ regaddr ] -> 

[stkaddr], [stkaddr. state] ; 
top_exq_pop_r ; [ s tkaddr ],[ s tate ] -> 

[ ], [stkaddr. state] ; 

f inish_exq_pop_r : [],[ s tate ],[ memaddr ] -> 

[ memaddr . state ] ; 

act i vate_exq_jmp_r ([instr. memaddr. state], []) -> 

[ state ] , [instr ] ; 

f etch_exq_jmp_r ([state], [regaddr] -> 

[state], [regaddr. state]; 
conver t_exq_jmp_r ([state], [val]) -> 

[ state] , [ va 1 ] ; 

f inish( [state] , [memaddr ] ) -> 

[ memaddr . state ] ; 

act i vate_cond ([], [val. memaddr. memaddr]) -> 
[memaddr. memaddr], [val ] ; 
f ini sh_cond ( [memaddr .memaddr], [bool]) -> 

[ memaddr ] ; 

acti vate_exq_i f([], [instr. memaddr . state]) -> 

[], [state], [instr], [instr], [instr], [ memaddr ] ; 
start_exq_if ([state], [regaddr], [regaddr]) -> 
[regaddr. state] , [regaddr. state] ; 

3^PP 1 f ( [state], [val ], [val ], [operator] ) -> 

[state], [operator, val .val ] ; 
cond_exq_i f([state], [memaddr], [val ], [memaddr] ) -> 
[state], [val. memaddr . memaddr ] ; 
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f inish_exq_i f(Cstate],[memaddr] -> 

[ memaddr .state 3 ; 

Properties 

act i vate_pr og ( pr og_avai 1 [ 3 , r eq_prog C m. q 3 ) => 
prog_f e tchC m. q3, req_fetchm(ll)[m.q3; 
get_i ns tr_pr og ( prog_activated[m.q3, avail _f etc hm( ll)[v3) 

= > prog_ins tr Cm. q 3 , req_atomof ins tr ( 1 2) C v 3 ; 
per f orm_prog (prog_instr[m.q3, 

avai 1 _atomof instr ( 1 2 ) [ i 3 ) => 
pr og_per f ormC 3 , req_exq ( 1 3 ) C i , m . q 3 ; 
f inish_prog (prog_perf ormC 3 , avai 1 _exq [ml . ql 3 ) => 
prog_avai 1 [ 3 , req_prog [ml . ql 3 ; 

acti vate_exq_monad (exq_avai 1 [ 3 , 

r eq_exq (l)[monad(o.rl.r2).m.q3) => 
exq_f or ( 1 ) [ 3 , exq_monad_activated[q3 , 
req_operator (ll)[monad(o.rl.r2)3, 
req_operand 1 ( 1 2 ) [ monad ( o . r 1 . r2 ) 3 , 
req_operand2 ( 13) [monad(o. rl. r2) 3, 
req_nex tmemaddr ( 1 4 ) [ m 3 ; 
s tar t_exq_monad ( exq_monad_act i vated [ q 3 , 

avai 1 _operandl ( 1 1 ) [ r 1 3 ) -> exq_monad_f etch[ q 3 , 
r eq_f etchr (15)[rl.q3; 

3PP 1 y_exq_monad ( exq_monad_f e tch[ q3, avail_fetchr(15)[v3, 
ava i 1 _operator ( 1 1 ) [ o 3 ) => exq_monad_app 1 y [ q 3 , 
req_app 1 y_mop( 16) [o.v3 ; 
s tore_exq_monad ( exq_monad_app 1 y [ q 3 , 

avai 1 _app 1 y_mop ( 1 6 ) [ V 1 3 , avai l_operand2( 1 3) [ r23 ) => 

ex q_monad_s tore [ 3 , r eq_s torer (17)[vl.r2.q3; 
f ini sh_exq_monad ( exq_monad_s tore [ 3, avail _storer(17)[ql3, 
avai l_nextmemaddr ( 1 4) [ml 3 ) => avai 1 _exq ( 1 ) [ ml . ql 3 ; 

acti vate_exq_dyad ( exq_avai 1 [ 3 , 

req_exq ( 1 ) [ dyad (o.rl.r2,r3).m.q3) => 
exq_f or ( 1 ) [ 3 , exq_dyad_act i vated [ q3 , 
r eq_oper a tor ( 11) [dyadCo. rl. r2, r3) 3, 
req_operand 1( 12) [dyadic. rl.r2, r3) 3, 
r eq_oper and2 ( 1 3 ) [ dyad (o.rl.r2,r3)3, 
r eq_operand3 ( 18) [dyad(o.rl.r2, r3)3, 
req_nex tmemaddr ( 1 4 ) [ m 3 ; 
s tar t_exq_dyad ( exq_dyad_acti vated [ q 3 , 

avail _operandl ( 1 1) [rl3) ,avai l_operand2( 12) [r23 
-> exq_dyad_f e tch [ q 3 , req_f etchr (15)[rl.q3 
r eq_f etch ( 1 9 ) [ r2. q 3 ; 

app 1 y_exq_dyad ( exq_dyad_f etch [q3, avail _fetchr(15)[vl3, 
avai l_operator( 1 1) [o3) ,avai l_fetchr( 19) [v23 
=> exq_dyad_app ly[q3, req_apply_dop( 16)[o.vl.v23; 
s tor e_exq_dyad ( exq_dyad_app 1 y [ q 3 , 

ava i 1 _app 1 y_dop ( 1 6 ) [ v3 3 , avai l_operand3 ( 1 8) [ r33 ) => 

exq_dyad_stor e [ 3 , r eq_s torerC 17)[v3.r3.q3; 



122 



f i ni sh_exq_dyad ( exq_dyad_s tore C ] , avail _s tore r ( 1 7 ) [ q 1 ] , 
avail _nex traemaddr (14)[ml]) => avail _exq(l)Cml.ql]; 

act i vate_exq_tr i ad ( exq_avai 1C], 

req_exq ( 1 ) C triad (o.rl.r2,r3,r4).m.q]) => 
exq_f or (!)[], exq_tr iad_act i vated C q 3 , 
req_operator ( ll)Ctriad(o. rl.r2, r3) ], 
r eq_operandl ( 12) Ctriad(o.rl.r2,r3) 3, 
req_operand2 (13)[triad(o.rl.r2,r3)3, 
req_operand3 ( 18) Ctriad(o. rl.r2,r3) 3, 
req_operand4 ( 110)Ctriad(o.rl.r2, r3, r4) 3, 
req_nex tmemaddr ( 1 4) C m 3 ; 
s tar t_exq_tr iad ( exq_tr i ad_act i vated C q] , 

avail _oper an dl( 11) Crl) ), avail _operand2( 12) Cr23 
avail _operand3 (13)Cr33,-> exq_tr iad_fetchCq], 
req_f etchr ( 1 5 ) C r 1 . q 3 , req_f etch (19)Cr2.q3, 
req_f etchr (lll)Cr3.q]; 

app 1 y_exq_tr i ad ( exq_tr iad_fetchCq] , avai l_fetchr( 15) Cvl], 
avai l_operator( 1 1) Co] ) ,avai l_fetchr( 19) Cv23 , 
avai 1 _f etchr ( 1 1 1 )[ v3 3 => exq_tr iad_app 1 y C q 3 , 
req_appl y_top( 16)[o.vl.v2.v33; 
s tor e_exq_tr i ad ( exq_tr iad_app 1 y C q 3 , 
avai 1 _app 1 y_top ( 1 6 ) [ v4 3 , avai 1 _operand4 ( 1 8 ) t r4 3 ) => 

exq_tr iad_s tore [ 3, req_storer(17)Cv4.r4.q]; 
f in ish_exq_tr iad ( exq_tr iad_storeC], avail _storer ( 1 7 ) C ql 3 , 
avail _nex tmemaddr (14)Cml3) => avail_exq(l)Cml.ql3; 

act i vate_exq_mov_r_r ( exq_avai 1 C 3 , 

r eq_exq (l)[mov_r_r(rl,r2).m.q3) => 

exq_mov_r_r_act i vatedCq], 
req_operandl (11) Cmov_r_r ( r 1 , r2) 3 , 
req_operand2 ( 12) Cmov_r_r(rl, r2) 3 , 
req_n ex tmemaddr ( 1 3 ) C m 3 ; 
s tar t_exq_mov_r_r ( exq_mov_r_r_ac t i vatedCq], 
avai 1 _operandl ( 1 1 ) [ r 1 3 ) => 

exq_raov_r_r_per f orm C q 3 , req_f etchr ( 1 4 ) C r 1 . q 3 ; 
s tor e_exq_mov_r_r ( exq_mov_r_r_per f orm C q 3 , 

avai 1 _f etchr ( 1 4) [ V 3 , ava i 1 _operand2 ( 1 2 ) C r2 3 ) => 
exq_mov_r_r_s tore C 3 , r eq_storer C v . r2 . q 3 ; 
f i n i sh_exq_mov_r_r ( exq_mov_r_r_s tor e [ 3 , avail _s tor er C q 1 3 , 
avai 1 _nex tmemaddr ( 1 3 ) C ml 3 ) => 
avai l_exq( 1 ) Cml.ql] ; 

act i vate_exq_mov_r_m (exq_avai 1 C 3 , 

r e q_e xq( 1 ) Cmov _r _m ( r 1 , m2 ) . m . q 3 ) = > 
ex q_mov_r_m_act i vated C q 3 , 
req_operand 1 ( 11) C mov_r_m ( r 1 , m2 ) 3 , 
req_operand2 ( 1 2 ) C mov_r_m ( r 1 , m2 ) 3 , 
req_nex tmemaddr ( 1 3 ) C m 3 ; 
s tar t_exq_mov_r_m ( exq_mov_r_m_act i vated C q 3 , 
ava i 1 _operand 1 ( 1 1 ) [ r 1 3 ) => 

exq_mov_r_m_per f orm [ q], req_fetchr(14)Crl.q]; 
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s tore_exq_mov_r_m ( exq_mov_r_m_perf orm[ q ] , 

avail _fetchr(14)Cv], avail _o per and2(12)Cm23) => 
exq_mov_r_m_s tore C ], req_storem[v.m2.q]; 
f ini sh_exq_mov_r_m ( exq_mo v_r_m_s tor e [ 3, avail _storemCql3, 
avai l_nextmemaddr( 13) Cml3 ) => 

avail _exq( 1 ) Cml.ql3 ; 

acti vate_exq_mov_m_r (exq_avai 1 C 3 , 

req_exq ( 1 ) C mov_m_r ( m2, r2).m.q3) => 
exq_mov_m_r_act i vatedCq3 , 
req_operandl ( 1 1 ) C mov_m_r ( m2, r2) 3 , 
r eq_oper and2 ( 1 2) Cmov_m_r (m2, r2) 3 , 
req_nex tmemaddr ( 13) [m3 ; 
s tar t_exq_mov_m_r ( exq_mov_m_r_act i vatedCq3, 
avail __o per andl(ll)Cm23) => 

exq_mov_m_r _per f orm C q 3 , req_f etchm ( 1 4 ) [m2. q 3 ; 
s tor e_exq_mov_m_r ( exq_mov_m_r_per f orm[ q 3 , 

avail_fetchm(14)[v3, avail_operand2(12)[r23) => 
exq_mov_m_r_s tor e [ 3 , req_s torer [ v . r2. q 3 ; 
fin i sh_exq_mo v_m_r ( exq_mov_m__r _s tore[3, avail_storer[ql3, 
avail _nextmemaddr ( 1 3) [ml 3 ) => 

avai l_exq( 1 ) [ml.ql3 ; 

act i vate_exq_push_r (exq_avai 1 [ 3 , 

req_exq ( 1 ) [ push_r (s,r).m.q3) => 
exq_push_r_act i vated[q3, 
req_operandl ( 1 1 ) [ push_r ( s, r ) 3 , 
r eq_operand2 ( 1 2) [ push_r ( s , r ) 3 , 
req_nex tmemaddr ( 1 3 ) [ m 3 ; 
f e tch_exq_push_r ( exq_push_r_act ivated[q3 , 
avail _o per an d2(12)[r3) => 

ex q_push_r _per f or ra [ q 3 , r eq_f e tchr ( 1 4 ) [ r . q 3 ; 
push_exq_push_r ( exq_push_r_per f orm [ q 3 , 

avail _fetchr(14)[v3, avail _o per andl(ll)[s3) => 
exq_push_r_s tor e [ 3 , r eq_push[ v . s . q 3 ; 
f i n i sh_exq_push_r ( exq_push_r_s tore [ 3 , avail _push [ ql 3 , 
avail __nextmemaddr( 13) [ml3) => 
avai l_exq( 1 ) [ml. ql3 ; 

act i vate_exq_pop_r (exq_avail[3, 

req_exq(l ) [pop_r(s,r).m.q3) => 

exq_pop_r_act i vated[q3, 
req__operandl ( 11) [pop_r(s, r) 3, 
req_operand2( 12) [ pop_r ( s , r ) 3 , 
req_nex tmemaddr ( 13) [m3 ; 
pop_exq_pop_r ( exq_pop_r _activated[q3 , 
avail _oper andl ( 1 1 ) [ s 3 ) => 

exq_pop_r _per f or m [ q3, req_top(14)[s.q3; 

s tor e_exq_pop__r ( exq_pop_r _per f or m [ q 3 , 

avail _top (14)[v3, avail _o per and 2 ( 1 2 ) [ r 3 ) = > 
exq_pop_r_s tore [s3, req_storer[v.r.q3; 
top_exq__pop__r ( exq__pop__r__s tor e [s3,avail_storer[ql3 => 



124 



exq_pop_r_pop C ] , req_popC s . ql 1 ; 
f i ni sh_exq_pop_r ( exq_pop_r_pop C ] , avail _pop C q2 ] , 
avai 1 _nex tmeraaddr ( 1 3 ) [ ml ] ) => 

avail _exq ( 1 ) C ml . q2 ] ; 

act i vate_exq_jmp_r ( exq_ava i 1 C ] , 
req_exq ( 1 ) [ jmp ( r ) . m. q ] ) => 

exq_jmp_r_act i vated C q ] , 
req_operandl (ll)Cjmp(r)]; 
f etch_exq_jmp_r ( exq_jmp_r_act i vatedCq], 
avai 1 _operandl ( 1 1 ) C r ] => 

exq_j mp_r_per f orm [ q ] , req_f e tchr ( 1 2 ) [ r . q ] ; 
conver t_exq_jmp_r ( exq_jmp_r_perf orm C q ] , 
avai 1 _f etchr ( 1 2 ) C V ] ) => 

ex q_j mp_r_conve r tingCq],r eq_atomof memaddr ( 1 3 ) [ v ] ; 
f ini sh_exq_jmp_r ( exq_jmp_r_conver t i ng C q ] , 
avai 1 _atomof memaddr ( 1 3 ) C ml ] => 
avai l_exq( 1 ) Cml.q]; 

act i vate_cond ( cond_ava i 1 C ] , req_cond (l)[v.ml.m2]) *=> 
cond_act i vated[ml.m2], req_atomof boo 1 ( 1 1 ) [ v ] ; 
f i ni sh_cond ( cond_act i vatedCml.m2], 
avai 1 _atomof boo 1 ( 1 1 ) C true () ] => 
avai l_cond( 1 ) Cml] ; 
f ini sh_cond ( cond_act i vatedCml. m2 ] , 

avai 1 _atomof boo 1 ( 1 1 ) C f a 1 se ( ) ] => 
avai l_cond( 1 ) Cm2] ; 

acti vate_exq_i f ( exq_avai 1C], 

req_exq ( l)Cif(o.rl.r2.ml).m.q]) => 
exq_f or ( 1 ) C ] , exq_i f _act i vated C q ] , 
req_operator( 11) Cif(o. rl. r2.ml) ], 
req_operandl ( 12) Cif(o. rl. r2.ml) ], 
req_operand2 (13)Cif(o.rl.r2.ml)], 
req_nex tmemaddr ( 1 4 ) C m ] 
star t_exq_i f ( exq_i f _act i vatedCq], 
avail _operandl ( 11) Crl],avai l_operand2( 12) Cr2]) 

-> exq_i f_fetchCq], req_f etchr ( 15) C r 1 . q ] 
req_f etchr ( 1 7) C r 1 . q ] ; 

3^PP 1 y_sx<l_i f C f_fetchCq], avai l_fetchr( 15) Cvl], 

avai 1 _f etchr ( 1 7) C v2 ] , avai 1 _operator ( 1 1 ) C o ] ) => 

exq_i f _app 1 y C q ] , req_app 1 y_rop (16)Co.vl.v2]; 
cond_exq_i f ( exq_i f _app lyCq], avail _nex tmemaddr ( 14) Cm2] 
avai l_operand3( 13) Cm3], avai 1 _app 1 y_rop (16)Cv3], => 

exq_i f _cond C q ] , req_cond ( 17) C v3 . m3. m2 ] ; 
f i ni sh_exq_i f ( exq_i f _cond C q ] , avai 1 _cond ( 1 7 ) C m3 ] ) => 
avai 1 _exq ( 1 ) Cm3 . q ] ; 

end am; 
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